Team assigns story points to bugs upon completion
I recently joined a Scrum team that has a practice to assign story points to bugs upon completion. This way their velocity reflects all of the work they do. Assigning story points upon completion sounds like a bad practice in general as story points are for estimating, but I see their point of having all the work they do reflected in their velocity.
I asked them why we don't estimate before starting to work on the bugs. They say that it's too difficult and they would sometimes give high estimations due to uncertainty but the actual resolution is often quicker.
What do you think of this practice?
I see their point of having all the work they do reflected in their velocity.
Well, that's the problem. Work ought to be accounted for by having a Done and valuable increment. Velocity provides an indication of the ability of the Developers to complete work to a Done standard, at a certain rate.
The purpose of estimation in Scrum is so the Developers can get their arms around how much work they can take on and complete in a Sprint. That's it.
The main problem right now is that work is not being Done. There are defects coming in. Remember that velocity is the rate at which work is Done. The Developers are accountable for quality, and yet for all we know, their velocity might actually be zero, by that standard. In other words, their so-called velocity might be fake. That's the issue I would concentrate on addressing.
The team has realized the fallacy of calculating velocity based upon estimates done before the work begins. You should congratulate them. Now, it is time to explain to the the purpose of estimating work and how velocity should be calculated. @Ian gives a good explanation that I have borrowed many times.
Remember that velocity is the rate at which work is Done.
How do you calculate the velocity of a car that needs to go from Point A to Point B? Once it starts moving can the rate at which it moves change? So how do you calculate how long it took the car to get from Point A to Point B? You wait until it reaches point B or when it is "done" with the journey.
There are a great many ways of calculating velocity of intellectual work. I have frequently used and suggest the use of flow metrics. The books by Daniel S. Vacanti are great for learning how to do this. Start with "When Will It Be Done". He explains the use of flow metrics like throughput and cycle time to determine velocity. There is even a plugin for Jira that will help you calculate the metrics.
I'm also going to point you to this old blog article by Ron Jefferies. He is frequently credited with creating Story Points. In the blog he gives the history, intentions and misuse of them.
I was serious about you congratulating the developers on your team. There are MANY that have not figured that out. They were creative with a solution and that solution could still work for them. But you do need to help them understand the importance of estimation. It doesn't have to be done formally like story points. But they should definitely be discussing the items in the Product Backlog and forming some types of estimates for the work before they decide what to pull into the Sprint Backlog.
Thanks for the reply Ian. Are you implying that Bugs should not be estimated at all then? There are endless discussions on this topic, but let's say that we agreed that it is beneficial for this team to estimate the bugs. What do you think of the practice of retroactively assign story points to them upon closure?
Also thanks Daniel. What I'm confused about is when you both say that velocity is the rate at which work is Done. To me that's clear, but I seem to read in between the lines that you both mean that when a bug appears 3 months later since delivering a functionality, you think the delivered functionality wasn't really done. Am I correct? I always interpreted it as "yes, it's done, but we're humans and we make mistakes so we need to fix something that isn't working as expected". I wouldn't then say that the functionality you delivered 3 months ago isn't Done. It just has a defect and needs some extra work. It seems to me that thinking that the delivered functionality wasn't really done means not accepting that bugs are part of the software development cycle and although you should avoid creating them, it's unrealistic to think that they won't ever be created.
Should the priority for a team that gets one bug reported a Sprint be on making sure there are no bugs created? I'm not sure, sounds like perfectionism to me. What do you think?
Are you implying that Bugs should not be estimated at all then?
If defects are raised during the Sprint before an item is Done, then there is no point in estimating them. They simply represent ongoing work which must be undertaken this Sprint before the item will be of usable quality.
If they are raised after the Sprint has been finished, and the Increment is in use, then those defects must be accounted for on the Product Backlog. The Product Backlog must tell the truth at all times about how much work we currently believe remains for the Product, including defects and other forms of technical debt. So they would need to be estimated there.
Attributing story point to defects after they are fixed makes little sense, because that work is no longer on the Product Backlog.
To me a product backlog item is a product backlog item. Treat them all the same. If a bug is found in production, it may or may not tie to a past product backlog item. You may or may not be able to tie it to something from the past. Even if you can tie it to a past item, it is too late to include is part of that item’s sizing.
Having all of their work accounted for has nothing to do with story points. They spent a Sprints worth of time doing Sprint things. Points are irrelevant. Estimating the size of something after you do the work is not an estimate, and is too late to be used for it’s intended purpose.
@Ian and @Ryan have given you the answer. A fix for a bug found in production is just another thing that needs to be done to the product in order to make it valuable. This is why I feel the Scrum Guide only talks about Product Backlog Items and not specific types. Treat them all equally.
If you find the bug during the Sprint, fix it while the developers still have the code base in that area fresh in their minds. The fix will be easier and quicker.
Agree with all the points mentioned above. My thought regarding this is rather than what story point value is to be given to bugs, the team should do an RCA to identify why the bug occurred in the first place and why was it not captured before it went to the end user (Production). Does the definition of done need to be updated to improve quality? Along with the RCA the bugs need to be triaged (based on priority, severity, classification, environment etc.).
The bugs identified as the must fix needs to be pulled into the sprint. There is no need to story point the bugs, but the team must dedicate some capacity in the sprint for fixing bugs (if required story point it during the planning). Adding story points after the bug is fixed is wasteful.
Story points and velocity are a nonsensical practice. Standardized story points may be of some help.
If one believes in esoteries then they may as well employ Tarok to estimate their time/costs.
You may read about why SP make little sense in my article:
"The conundrum about Story Points — pointless or not?"
https://medium.com/@maciejjarosz/the-conundrum-about-story-points-pointless-or-not-b5d715180c96
Basically read materials on Glenn Alleman's blog, he's superb with maths & statistics.