This project is read-only.
1
Vote

feature suggestions

description

Awesome tool. I used to use Telerik's WIM, but without access to source code or any customizability it wasn't proving very useful. This one, however, shines on both counts.
 
Couple feature suggestions:
 
  1. When a team member is not found in the TeamMemberList (inside CreateTeamMember) return null instead of throwing. This allows me to restrict which team members I show through the team.xml file. Why do I want to do this? I don't, for instance, want to show PM work items or bugs -- I'm primarily interested in showing dev/test. Or I, as the dev lead, want a display outside my office that shows only the status of my devs. With this simple change I can do that. (I've already done this on my local version of the sourcecode.)
     
  2. Integrate http://www.mountaingoatsoftware.com/alt-releaseburndown style reporting for the burndown. This would bemuch more useful than what's shown right now. I haven't tried tackling that yet.
     
  3. Allow slideshow reporting of multiple iteration paths. This would allow a single display for multiple scrum teams.
     
  4. Allow more flexibility in choosing what WI types get included in the report. Looking at "TeamMembersListViewModel.cs:596" you're selecting only SprintBacklogItems. What if I want to include bugs? Suggest modifying IWorkItemAdapter to have a "ShouldIncludeInSprint" property -- will be more flexible. Also a change I've made on my local copy. (Update: there's actually a few places in code where you do w.Type == WorkItemType.SprintBacklogItem -- that really ought to be up to the process adapter to decide. (I suppose I could just make the WorkItemAdapter return SprintBacklogItem for a Bug... but that seems more like a hack than a by-intent workaround.)

comments

partnerinflight wrote Aug 16, 2011 at 7:13 PM

Thanks for the response. Some comments:

re point 3: As long as the feature team is prominently displayed in each slide I am not sure this'd be much of an issue. Problem is without this functionality the tool cannot be deployed on a project level (say in the hallway on a large flat-screen.) Thus its usefulness is decreased.

re 4: actually I must confess to misusing the tool somewhat. We do not currently have a true scrum implementation on our team, rather we're more ScrumBut -- we have a stabilization period. So I'm using the tool to display the progress of the stabilization -- how we're progressing against incoming bugs, etc. I could potentially just make a separate template for this use, but from an API flexibility point of view I do think you have a design issue -- if you're going to delegate to work item adapters to interpret a particular TFS entry, it would (to me) make more sense to to allow them to decide whether a particular entry should be counted on a wider scope of attributes than just WI type... having a function in the interface gives you that flexibility. Returning SprintBacklogItem is a hack -- if I wanted to, say, exclude Test or PM WIs from the tally, I'd have to "hack" them to return type as Unknown or something. See what I mean?

Basically I see this tool as something more than a mere sprint monitor. It could easily become a Project monitor, independent of what process you're following.

PombeirP wrote Aug 17, 2011 at 12:12 AM

I understood your point, and I can see that its a good idea to abstract the work item type if we have a conceptual need for it. It's just that until now the template adaptor has served just one purpose, and that is to abstract differences in the data representation of each process template. What you're proposing to do now is to expand the concept to also have some kind of intelligence in how you interpret each work item. You could potentially end up with multiple process template adaptors for a single process template, something that would not have made sense at the time I designed this. I'm not saying it is wrong, merely explaining the current rationale. I will give it some more thought when I have some spare time to dedicate to the project. Thanks for the input though!

partnerinflight wrote Aug 17, 2011 at 12:24 AM

Yup, makes sense. Thanks again for developing such a great tool!

wrote Aug 18, 2011 at 12:06 AM

Resolved with changeset 69084.

PombeirP wrote Aug 19, 2011 at 12:35 AM

** Closed by PombeirP 8/17/2011 4:06 PM

PombeirP wrote Aug 19, 2011 at 12:36 AM

wrote Feb 14, 2013 at 3:17 AM

wrote Nov 28 at 8:58 PM