Which PBIs (Product Backlog Items) should we estimate and which not? Should we estimate everything in story points or not? I will try to explain in this article why some of the PBIs should not be estimated using story points but rather in different ways for the benefit of the team.
Copying from https://www.mountaingoatsoftware.com/blog/what-are-story-points:
"Story points are a unit of measure for expressing an estimate of the overall effort that will be required to fully implement a product backlog item or any other piece of work. When we estimate with story points, we assign a point value to each item.
The raw values we assign are unimportant. What matters are the relative values. A story that is assigned a 2 should be twice as much as a story that is assigned a 1. It should also be two-thirds of a story that is estimated as 3 story points.
Instead of assigning 1, 2 and 3, that team could instead have assigned 100, 200 and 300. Or 1 million, 2 million and 3 million. It is the ratios that matter, not the actual numbers."
In the same article, Mike Cohn says that in the story point we include three things. The amount of work to doThe complexity of the work. Any risk or uncertainty in doing the work
Also a past article which explains some things for estimation can be found here.
The "Value" keyword and meaning has its origins mostly in Lean and specifically from Toyota's Way of working. Copying from Craig Larman and Bas Vodde in "Scaling Lean & Agile Development":
Value---The moments of action or thought creating the product that the customer is willing to pay for. Imagine a customer observing the work in your office. At what moments would they be willing to reach into their pocket, pull out money, and give it to you?
Also I would add the value extension of what ROI/benefit the customer gains from the deliverable software increment. This is also very important to have in mind, but in this article what I mean by value is mostly the internal action of an organization that tries to be more agile.
So, let's try to map the above picture to the things a team does and see if it falls under these and how much. The things usually an Agile Team does are:
1) User Stories
2) Technical Tasks (will see what we mean)
3) Fixing Technical Debt
4) Fixing Bugs
5) Deployment of the application
Let's take them one by one and see which of those should be estimated using story points and for which an alternative way should be used.
Should we estimate User Stories?
I think we don't have to analyse too much here. User Story Points are by definition for User Stories. User stories clearly describe customer value so we want definitely to estimate them using those.
Also we assume here that a normal backlog will contain at a majority user stories and epics as we move downwards to it.
Scrum says PBI (Product Backlog Items) but in the context we assumed that the primary format to describe our requirements are User Stories and thus story points for the estimation.
Should we estimate Technical Tasks?
Well now the problems begin. What is a technical task? In the end everything is a technical task. The problem comes with the size. You may have a pretty nice user story but the technical work it requires is very big.
Then you have the following options:
a) Try to split the user story in terms of business perspective and at the same time fit also from technical perspective the underlying work to each new item. This might not be possible always. For example setting an initial infrastructure for something may not be possible to break in smaller pieces. If you try to encapsulate it in one of the user stories you have, then you might have a big estimation number for that user story. The problems that this create and potential solutions can be found in this past article.
b) Encapsulate the technical work (which as we said cannot break in meaningful or possible small deliverables) to one or more technical tasks which possibly will NOT follow the INVEST model either, and also will not be able to fit as subtasks to a user story (due to size). The user story will still have subtasks of course but limited to a size that will not make the user story an Epic without business breaking options.
Another form of technical tasks, are the ones not relevant with any User Story directly or indirectly. For example, we want to upgrade the version of library and that requires also code changes.
Normally, we should wait until somehow we are "forced" for some business reason to do an independent task like that, but let's face the reality that this happens a lot and it's difficult to map it with a user story.
So, should we estimate the technical tasks using story points? I believe the answer is yes ONLY for the technical tasks that derive from point (b) above. Which means only for technical tasks that derive from user stories, as a prerequisite maybe work, and in general from items that we can see evidence of customer value.
The rest technical tasks could be estimated using T Shirt Size or time of how much effort the team will spend doing them, so then they could be more conservative when they pick estimated user stories for the sprint.
Should we estimate fixing Technical Debt
Is fixing technical debt an act of value? I think not, based on the terms we defined in the 3d paragraph. Fixing something you shouldn't have done that way clearly, does not deliver value to the customer but only to the team.
Nevertheless, there is a type of technical debt which most of the times we cannot foresee. According this article, it is called “Accidental/Outdated design Tech Debt”. A common case that falls under this technical debt is the need for scaling the application to support heavy load. Similar cases like that could be considered as Technical Debt that is necessary to fix if you want to be in position to grow.
A word here for continuous refactoring. Continuous refactoring is not fixing technical debt. It is exactly the valuable action a team should do in order to prevent the accumulation of technical debt so the they have always the option to produce valuable work in the future too.
Having said that, I believe fixing technical debt should NOT be estimated using story points. Again I will say that the team should estimate in some way the work to be done for the technical debt fix, so they could be in a position to carefully select other User Stories too knowing what else they have to do in the Sprint.
Should we estimate fixing Bugs
Is fixing bugs an act of value? I think again it isn't, based the terms we defined in the 3d paragraph. If fixing technical debt is one bad thing if a team have to do in a sprint, bug fixing is ten times worse.
Again fixing something that should have worked initially and give the proper value, doing it afterwards takes time from the team from working on the next valuable thing.
With that in mind bugs should not be estimated using story points.
Should we estimate Deployment of application?
Deploying the application requires effort. It is a technical task and sometimes it could be painful. Is deployment effort an act of value? Again based the terms we defined in the 3d paragraph it seems that it isn't.
Let's have a closer look. Should a customer pays for the effort you do to deploy the application? Think about you buying a product from Amazon. The value you want to pay first is for the product you buy. The cost of delivering it to your home is something different. You don't see it as part of the product and that's the same for software.
Delivering the product should be separated from the actions that are involved to create a valuable product increment. Delivering an increment is a process that must be monitored not by story points, but from time and people involved perspective.
This process prevents people from creating something valuable so we want to automate it as fast as possible. You must know how much time it needs a finished item to reach production. Then you should find ways to automate so that the minimum people are involved, and also that the time to reach the customer is the
What will happen to velocity if we don't estimate them?
If you have a lot of not estimated PBIs in story points, thus a lot of non valuable work in each sprint, velocity will be low and calculated only based to user stories and valuable technical tasks included in the sprints. All the other will be non valuable work.
But that is OK (not for the organisation or customer, but for future delivery estimates)! Since a normal product backlog contains in it's majority User Stories, if a product owner wants to see when a batch of estimated user stories in the backlog will be delivered, he will divide the velocity of a team with the total summary of the story points for these stories.
If the velocity is based on user stories delivered in the past, then he will be more confident of that projection since the items he wants to check for delivery are again user stories and not bugs, technical debt or other not valuable items.
In short, if in the backlog you have estimated sizes of apples then the velocity should have been created using bites on apples you ate in the past. Not from different fruits.