Michael's dashboard

Beja,

The order in the icebox / product backlog determines priority. The higher-up items are highest priority....

So setting an actual priority level could get very confusing.

However, I do wish there was a way to somehow flag certain items as "Critical" and change their box color to orange or red or something. In a few rare cases, it would be great to have some visual indicator to make things pop out.

A second idea (if you need some priority setting) is to use labels. For example: "Urgent". That way you can filter out just the urgent stories. We do that sometimes.

Hope that helps you.

Thanks,

Michael

I have to say, for me this may be the single most valuable feature Pivotal could add.

In most ways, Tracker's elegance destroys the "big" agile tools like Rally, Serena, Target Process, etc. I think the only real thing those tools have on Tracker is the ability to support multiple teams on a project AND/OR a single team working multiple clients/projects.

If Pivotal could "integrate" with itself as Jeff Suggests (or support "Parent" projects that pull in child projects) it would have this nailed too.

Hoping to see something like this soon!

Noah,

Great point. I guess I did get a bit off the core idea, which is not whether or not to count bugs, but to be able to separate out two types of velocity. I do support better reporting on bugs vs. features.

For example, it wold be very helpful to add a toggle to the Story Type Breakdown chart to switch between "number of stories" and "story points". I think that would report what you are after. You could see how many story points per iteration are going to bugs as you move along.

I am totally in favor of adding more analytic reports. I just don't like mucking with Velocity because it means something very specific, and is at the core of most agile. I think it is confusing to introduce 2 (or more) Velocity numbers.

Strictly, Velocity is a measure of how much product backlog effort a team can handle in one sprint. It's primary purpose is to predict delivery dates, and aid in planning.

The product owner is responsible for calculating business value, which will be very different from Story Points. Story Points are a measure of relative effort, never business value. 5 Story points might deliver little value or huge value. Business Value combined with Story Points is what allows a PO to prioritize features (and bugs), and decide what goes into a release or not. Again, Cohn's book has a great treatment of the PO role and prioritization based on various business value approaches.

Given that, the only thing that should really matter is total velocity, and backlogged bugs should be estimated. Otherwise, you won't get an accurate prediction for deployment, and planning is difficult.

So, having some reports that allow better vision into bugs vs. chores vs. features is great. All for that. I just think it would be a negative effect to show multiple velocity scores...because what is that actually useful for?

For example...say your Feature Velocity is 20, and your total is 40. 20 Can't be used for prediction. If the number of bugs in the backlog drops (or gets prioritized lower), your feature Velocity will shoot up. If bugs get prioritized, it will drop. But now, "Feature Velocity" looses predictive value. At that point, it is report data, not velocity. It fluctuates wildly based on the way the PO chooses to prioritize the backlog. The only thing that is really going to matter is your total velocity.

However, team and managers may see value in a report of bugs vs features, relative effort being devoted to one over the other. For example, if 50% of my story points are going to bugs, I say "whoa! We're being very sloppy. We need to fix something in our process." There is value in those reports. But I don't see any value in 2 Velocity numbers.

My vote is: please give us more reporting / chart tools! Don't mess with Velocity.

Ohh.. And Pivotal rocks regardless! Woo.

Some good debate on this issue. We have been having similar debates internally using Tracker.

Our conclusions so far are:

1. Unplanned bugs/support work should get zero points. Anything that MUST be done (whether we want to do it or not) should get zero points. These unanticipated interruptions will have the affect of lowering velocity. They account for themselves over time. I think this is the point that Alan is making.

2. We DO assign points to bugs/chores that sit in the icebox/backlog and are scheduled at the product owner's discretion. They are effectively "features" at that point. They are not something we are forced into--the product owner makes the call about how valuable they are, or whether they should be resolved at all (just like a feature).

I think Mike Cohn nails this in Agile Estimating and Planning. Check out page 154. The point is: all defects found during the iteration are handled there, and get no points. "Outside an iteration, the whole idea of a defect starts to go away. Fixing a bug and adding a feature become two ways of describing the same thing."

All that to say: I really don't see anything wrong with Pivotal Tracker on this issue (now that it has the option to estimate bugs). It has all the tools necessary to preserve both Velocity and Estimation capabilities. It may just require a bit of tweaking to the way your team uses it.

The option to estimate bugs / chores has been Huge. I think at this point adding new features to handle this would just make Pivotal bloated and confusing. It has everything you need to handle either approach (commit mode and optional bug estimating make either possible).

Side note: Scrum actually seems to disagree with Cohn on this point, and claims bugs never get points. This is also apparently the default Pivotal position. However, this requires commitment based sprint planning, NOT velocity based planning. There is a big difference.

The Scrum solution to this is some version of: during sprint planning, the team must determine how many bugs they can get done, and lower their commitment accordingly (dropping story point commitment below velocity). It really amounts to the same damn thing as I see it. Either way, you MUST accommodate bugs and their effect.

I prefer Cohn's approach because it makes the cost of outstanding bugs clearer AND properly represents the Product Owner's discretion and prioritization of bugs.

Hmm. Well, it sounds like you are after some sort of individual productivity information. I don't think Velocity is the same thing, even if only one person touches each issue.

Velocity is a very macro-level concept. At the individual level it sort of breaks down. Individuals will work at different rates on different types of problems. Are you estimating as a team, or each as an individual?

Still, if you find some value in this, it doesn't look like there is a good way to calculate this in Pivotal. Either look in "Done" and calculate manually, or maybe export each iteration to a CSV, and use that to calculate?

That's about all I can think of. Good luck.

The time limit seems like a poor idea. I often want to edit or delete well after 15 minutes. – Michael, on January 21, 2010 17:36

I am not sure how this could be measured objectively?

Typically, multiple people on a team "touch" any given issue, so how do you calculate velocity for a person? I suppose if one and only one person worked on each issue, it could make some sense....but then who is designing, testing, code reviewing, etc?

If more than one person touches an issue, individual velocity becomes meaningless.

We also used a blocked tag.

However, I think there is definite need for an actual blocked state (maybe that turns the issue pink/red/orange or something). Blocked items should be strongly distinguished from items in other states.

I suspect a lot of people could make use of a "blocked" state of some kind?

New iterations also start out in auto mode, and pull in all the new stories.

It feels like commit mode should really be a project-level setting. You either plan iterations based on team commitment, or you trust calculated velocity and let the iteration auto-fill.

This is a terrific feature idea. We have slightly different needs for the same sort of thing:

Some projects are large enough to occupy a full team. Other times, we may have a team working on "rats and mice" for several clients. Each of those clients would have an individual project that might only have 2 or 3 stories in the current iteration. However, at the team level, we want to track a 2-week iteration made up of 5 or 6 little projects like this. Velocity and progress really only make sense at this "parent" level. Any given individual project will fluctuate wildly.

Note: This is different than Sean's described scenario, which sounds like a way to scale agile to multiple teams (scrum of scrums). My scenario focuses on a single team working multiple small projects. But the solution might be the same.

It would be ideal if you could create a "parent" project. This project may or may not allow its own stories, but the backlog and icebox would show all stories from its sub-projects. Maybe you could specify a relative priority for the sub-projects to establish ranking? Or, ideally, the stories would just get a parent-project ordering/priority unique from the child project. Thorny problem I guess.

The reason "project-tagging" in a single project won't work is because we potentially want clients looking at their project stories, without seeing other projects'/clients' stories.

Michael