Our company adopted scrum as our method for development over a year ago. And to this day, we’ve yet to get it entirely right. Over the months we’ve had to address issues ranging from “What do we do when critical issues come up?” to “Who should be a part of our daily scrum meeting?” to “What the hell is a story point anyway?” But one such problem that our Product owner recently brought up is, “Should we really be story pointing bugs?” And the answer, of course, is… well, actually, no one can really agree on an answer.

Well, let’s start out with why we all originally said yes. In any given sprint, our team will have to commit to some handful of stories and bugs off the top of the product backlog. If both the stories and bugs are story pointed to the same scale, then we have no problem deciding how much we can commit to this sprint given our previous velocities. And for a while, this worked fine.

But let’s look at this from the product owner’s point of view. Let’s say we’ve just released the next version of our product and now our product owner is looking over the backlog, trying to figure out how many sprints we’ll need to complete the required features (let’s say there are 10) we need for the next release. Each of these features gets defined as a story. For the sake of simplicity, let’s say they all have a story point value of 10, resulting in a total of 100 story points. In our past sprints, our velocity has averaged 20 story points. So our product owner can set the next release date for five sprints from now. Easy!

So now we skip ahead to the end of the second sprint. In the first sprint, two stories were completed, and the same with the second sprint. Right on schedule! But in the third sprint, we find a problem with our implementation of the first story we completed two sprints ago. Alright, no big deal, we’ll make a bug out of it, story point that bug at 10 points and put it in with the next sprint. The same thing happens in the fourth sprint with the second story we ever completed. So we do the same thing; we story point the bug at 10 points and put it in our final sprint. But wait. We’ve just finished the last sprint but we still have to stories to complete. We have to push the release date back by a full sprint!

Those bugs threw off our estimate. But what can we do? We have to do them. Those features aren’t release ready unless those bugs are resolved. If we had known that those issues would come up, we would have evaluated the first and second story at 20 story points and the product owner would have known we’d need six sprints instead of five. But we couldn’t have known that about those issues. Technically, those stories should never have been marked as complete back in the sprints they were assigned to. But regardless of how fine-tuned our testing and quality assurance is, problems will slip through the cracks and issues will arise down the line. So what do we do?

Well, let’s consider what happens if we stop story pointing the bugs. Then we would have completed the original 100 story points and not the 120 points we had when we include the bugs. But since we completed those story points over the course of six sprints, our average velocity was about 16.7 (100/6) as opposed to 20. So now for the next release (again, let’s say 100 story points), the product owner knows to allocate six sprints instead of five which creates a realistic deadline which genuinely reflects how long it would take to finish those stories. And since you’ll ultimately be putting less into any given sprint, you may find you’ll reduce the likelihood of bugs cropping up in the first place, which is really the way to go.

But now here’s the problem, if you don’t story point the bugs, how do you know how many bugs will fit into a sprint alongside with stories? So what does the team do to know how much they can commit to? Well, whatever they want! If the team wants to story point bugs, they can. The product owner won’t care, nor will he ever take those estimates into consideration. The product owner will prioritize the bugs and determine when and if they get completed, but that’s it. He’ll never use these “bug points” for his own estimates. Those story points on the bugs are just a tool the team is using for themselves. If the team finds they don’t need the bugs story pointed, and that they can figure out how much they can do after breaking the bugs and stories into tasks, great! If the team can look at the bugs and stories and “just know” how much they can do by the aching of their knees, then good for them! The story points are a tool for the product owner. The team may also find them useful for determining how much they can do.

Ultimately, whether you story point bugs or not is up to your team. If your team needs to story point the bugs for their own convenience, then do so. Your product owner shouldn’t care either way.

[Image via: Simon Bennett]

Follow

Related posts: