Loading Profile...
Bugs and Chores should be estimable, without counting toward velocity.
Another thing I'd like to be able to do is *estimate* bugs and chores, but still have them *not count* towards the velocity.
When I add a new bug into the current iteration, I'd assign it an estimate of, say, 3.
Three corresponding points *must* drop off the bottom of the current sprint, right ? We have to let our customer know we won't get it all done and drop 3 points from our commitment.
Of course, when we mark the story complete it shouldn't count 3 points to our velocity, I'd say, but like a spacer image on a webpage it should have a size, and move something else out of the way.
When I add a new bug into the current iteration, I'd assign it an estimate of, say, 3.
Three corresponding points *must* drop off the bottom of the current sprint, right ? We have to let our customer know we won't get it all done and drop 3 points from our commitment.
Of course, when we mark the story complete it shouldn't count 3 points to our velocity, I'd say, but like a spacer image on a webpage it should have a size, and move something else out of the way.
I’m still happy
23
people like this idea
I like this idea!
Tell me when this idea gets some attention.
The more people who like this idea, the more it gets noticed.
The more people who like this idea, the more it gets noticed.
The company has this under consideration.
The best point from everyone
-
I've read all the back and forth debate about estimating bugs/chores, I'm familiar with Pivotal's stance, etc... but I just can't wrap my head around this:
If (1) Tracker automatically moves bugs & chores from the backlog to the current iteration and (2) Tracker doesn't allow point values to be assigned to bugs and chores then (3) Tracker has the potential to add an infinite number of bugs and chores to the current iteration.
In other words, if my current iteration is filled to 14 out of 15 points, and I have 367 bugs and chores at the top of my backlog, they will ALL be moved into the current iteration. This just doesn't compute.
The workaround seems to be manually intervening in order to move stories around (and potentially artificially "block" them from getting added to the current iteration)... but Tracker supposedly promotes an automatic, hands-off assignment of stories. What gives?
I’m frustrated
3 people think
this is one of the best points
-
Inappropriate?Hi Alan, thanks for the suggestion. The idea behind the current model is that as long as the ratio of features to bugs/chores remains relatively constant, Tracker will predict release dates reasonably well, without the extra overhead estimating overhead, and multiple types of points (feature vs total). It is frequently the case, however, that as you get closer to a release, the number of chores/bugs in the backlog increases, and in that state, date projections become less accurate. At this point, though, you're usually fairly close to the release.
It is possible to enable estimation of bugs/chores (in project settings), but then you lose the important distinction between feature output, and total amount of work completed. Perhaps a simple change would be to display both the total and feature velocity. We'll discuss it in our next feature planning meeting.
Thanks again, and hope Tracker is working well for you otherwise.
dan -
Inappropriate?Hi Dan, Thanks for the feedback.
As I mentioned in my other post [ http://tinyurl.com/4df5wx ] I *love* Tracker. I've been waiting for someone to write this tool for nearly ten years (and tried myself a few times :-)
I think, in my head, I don't need to see both totals at the end. Features are the only thing that actually count. All a bug does is knock out our ability to deliver some feature in that iteration. It has a size therefore, but has the effect of reducing velocity. We had to drop this 3-point story because of this 3-point bug. This is assuming that bugs aren't planned in to the iteration, but surface midway.
This is an awesome tool. Please take my little nitpicks as just that. I've been living and breathing XP since 1999 so I'm not short of a humble opinion or two :-)
Thanks,
Alan -
Inappropriate?I agree -- we're tending to not use the Bugs and Chores because if we do so we can't allow for the time they're going to take. I understand about them not strictly being part of delivered customer value, but really they are, and in any case, there can be no doubt that they take time and therefore reduce the number of points that can be completed in an iteration. -
Inappropriate?I've read all the back and forth debate about estimating bugs/chores, I'm familiar with Pivotal's stance, etc... but I just can't wrap my head around this:
If (1) Tracker automatically moves bugs & chores from the backlog to the current iteration and (2) Tracker doesn't allow point values to be assigned to bugs and chores then (3) Tracker has the potential to add an infinite number of bugs and chores to the current iteration.
In other words, if my current iteration is filled to 14 out of 15 points, and I have 367 bugs and chores at the top of my backlog, they will ALL be moved into the current iteration. This just doesn't compute.
The workaround seems to be manually intervening in order to move stories around (and potentially artificially "block" them from getting added to the current iteration)... but Tracker supposedly promotes an automatic, hands-off assignment of stories. What gives?
I’m frustrated
3 people think
this is one of the best points
-
Inappropriate?I agree. I need to be able to assign points that will control how many bugs get assigned to an iteration without them affecting velocity reporting.1 Comment Add a comment
This is one of the best points
-
I think if you are fixing a lot of bugs it *should* affect your velocity reporting. You will get less useful stuff done if you let quality slip and start spending a lot of time fixing bugs. If you choose to schedule a bug in, something else isn't going to get done, but you don't get to keep the points. You spent 2 days fixing a bug instead of delivering a feature. -
Inappropriate?Velocity is simply being asked to do too much, proof of which is the constant struggle people have matching their project reality up to it.
Is it an indication of business value completed? Why are developers determining business value? Is it supposed to be a prediction mechanism? If so, why can't I just nail velocity to some number if I've gone through a big chore+bug fixing phase - why must I live with the prediction part being broken when I'm absolutely certain that my team will be performing at a higher level?
Etc. I believe the answer is to open up tracker: make the types of stories user-configurable, make it so you can have multiple "velocity"-like measurements, again user configurable. This would lead to user experimentation and possibly innovation around agile planning. Wouldn't it be great if I could then share my tracker recipe on a forum like this and you could just plug it into your project?
I’m undecided
2 people think
this is one of the best points
1 Comment Add a comment
This is one of the best points
-
I'm not really in favour of that level of configurability. That's the big problem with Mingle. Too many options.
I think the simplest thing is for every single type of thing I can schedule requiring an estimate and contributing to velocity.
Simple, consistent. -
Inappropriate?I think Steve_c made a good point when he said "Velocity is simply being asked to do too much". Perhaps a solution would be to have two measures. A Total Project Velocity and a Feature Velocity. This would allow the team to measure the business value they're delivering per iteration as well as plan several iterations out. With this system you don't have to sacrifice the predictability of Tracker if you do a week of only bug fixes or operations works. Tracker could then provide feedback based on the ratio between your Total Velocity and your Feature Velocity to help teams make sure they're actually delivering business value.
I’m excited
-
Inappropriate?I'm having the same trouble as others have mentioned, namely that I get too many Feature stories on my plate if I have many bugs during that iteration. While I understand that the bugs' points shouldn't count toward my velocity, it does affect the number of Feature points I can reasonably accomplish during the iteration.
Note that uneven distribution of bug rate can happen for reasons other a release is near. For example, at my company we take turns being "on call" to field incoming bugs reported by customers. So the one week I'm on call, I can't get anywhere close to my usual velocity.
I’m frustrated
4 Comments Add a comment
This is one of the best points
-
Sorry, this is a bit rambly,
I think there are two concepts at play here.
Velocity = how many feature points I got done last iteration
Budget = how many points I can sign up for in this and future iterations
At the start of a new iteration, we set Budget to equal Velocity. We can now forget about Velocity until the start of the next iteration and deal with budget.
If I add a bug into this iteration, an estimate on it would take out a chunk of the Budget and drop a corresponding feature out the bottom. My Budget is unchanging.
At the end of this iteration I calculate my new Velocity based on the total delivered feature points (this excludes bugs).
What's interesting to me is that in effect Velocity (an output value) works fine when bugs dont count towards it. If you do a lot of bugs, you get less done, so your points achieved goes down.
This means your corresponding Budget for next iteration goes down.
This works well if bugs are scarce and unplanned, added to iteration N mostly as a result of stuff we did on N-1.
"Why did our velocity go down and why didn't we hit what we signed up for?"
"We added a lot of bugs during the iteration.
"What does that tell us"
"We did a bad job of quality control on the previous iteration, so we do need to slow down and do less, but better."
Where it doesn't work so well is in doing iteration planning with a known set of bugs. If I want to deliberately spend my Budget on some features and some bugs with impunity, they *have* to be accounted for in my (output) Velocity so they can be used in my Budget going forward.
I think this split in usage is at the crux of why this question has caused so much debate..
With the former view, the current behaviour is technically right on the money. A bug added during the iteration will likely mean a feature doesn't get done and velocity goes down.
The only problem is we learn that too late. You don't see that knowledge reflected in the plan until the end of this iteration when velocity is measured and the plan reflows to accomodate the not-done feature. If Bugs had size we'd see the knockon planning effect immediately as the story would drop to next iteration and the release plan would reflow. In essence this is what I'm proposing. A Bug introduced to an iteration should knock out a story if it puts us over budget.
Tracker doesn't seem to be designed for the latter approach, where bugs are sitting in the backlog and being scheduled like stories. We effectively gather up a big bunch of bugs using Tracker as a bug database, and then choose some bugs to plan into every iteration along with features with eyes open. In that approach velocity doesn't equal features done, its about work done and all work that gets ticked off in an iteration "counts" for scheduling purposes.
In an XP team, the first view is the predominant approach. Theres a zero tolerance approach and if a bug is found, it gets allocated and fixed, no debate. If there are too many bugs, velocity goes down and down as we're spending too much time fixing bugs instead of writing new stuff.
I'm tired now and going to bed :-) -
" I get too many Feature stories on my plate if I have many bugs during that iteration."
This should only happen for one iteration. Next iteration your velocity will be lower as you didn't get all those stories done, so you dont get so many features on your plate.
Yesterdays Weather is marvellous for this kind of self-correction. -
"This should only happen for one iteration. Next iteration your velocity will be lower as you didn't get all those stories done, so you dont get so many features on your plate."
The problem with my on-call situation is that it lasts only one iteration, so I won't benefit from the self-correction. My next on-call won't be for another 2 months, so PT will have forgotten all about it by the next time I'm on-call.
I suppose I could set my Team Strength below 100% to get the behavior I want. It still seems like a cleaner solution to allow bugs/chores to have estimates that bump features but don't count toward velocity, though. -
"I think this split in usage is at the crux of why this question isn't easily resolvable."
Sure it is. Leave the current behavior in as the default and give me an "I know what I'm doing, make velocity X" override. Done. -
Inappropriate?"It still seems like a cleaner solution to allow bugs/chores to have estimates that bump features but don't count toward velocity, though."
Yes, yes, yes. :-) What concerns me is switching to them having estimates *and* counting toward velocity. I think that would be wrong. the estimate on a bug has relevance to the current iterations Budget, but not future iterations velocity (imo).
I’m enjoying this
1 Comment Add a comment
This is one of the best points
-
"Yes, yes, yes. :-)"
Then I think we're in agreement. :) -
Inappropriate?I think the debate arises from having two different measurement purposes collapsed into velocity. These purposes are determining 1) how much customer facing value is being delivered 2) increasing estimation accuracy for decision making.
Not including points for bugs and chores allows monitoring customer facing value as the primary measure. But, it reduces accuracy of estimates and therefore decreases the ability of the project manager to decide which task to do next.
I personally have been bitten by the inability of estimating refactorings that are categorized as chores. Yes, it's good to do refactorings as soon as possible, but it's good to know the relative point cost in comparison to customer facing value when working against hard deadlines.
I think the best solution would be to give points to bugs and chores to allow for more accurate cost based planning and have separate measures for total velocity and feature velocity.
1 person thinks
this is one of the best points
-
Inappropriate?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.1 Comment Add a comment
This is one of the best points
-
Michael,
Great reply!
My main point is that there is a difference between feature and chore/bug velocity. It would be great to be able to separate that out.
Alan's suggestion of not counting bug and chore points towards the velocity would solve that. No additional bloat would be necessary if the "Story Type Breakdown" shows the total velocity of features, bugs, and chores by points. Not sure if a single settings checkbox to "Include bugs and chores in velocity" would be necessary to support current user expectations. -
Inappropriate?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.
1 person thinks
this is one of the best points
-
Inappropriate?> say your Feature Velocity is 20, and your total is 40. 20 Can't be used for prediction.
Michael yes - you are right! If using points with bugs & chores then velocity must be based on total points to be predictive.
With this new realization, my desired feature is for estimated chores and points to use points in the story-type breakdown chart instead of using a single unit on the y axis.
This will keep the estimation accuracy of velocity and allow visibility into feature velocity. Of course, business value is out of the scope of these numbers.
And yes... Pivotal Tracker rocks!
EMPLOYEE
