If you noticed the topic, I have not called it ‘story sizing’ but just ‘sizing’. That is done intentionally here as that is the aspect that I am going to discuss here.
It is well known that Product Owners want to know how much value team is delivering every sprint. And management is also interested in the outcome and not output. While that is true, when I ask anyone what is size? The answer is invariably how much work is on hand and not how much value is on hand. So I am now trying in one of the groups where I am coaching the aspect of size representing how much work on hand including all kinds of work in the backlog and not specifically focusing on value alone as how much value on hand.
How does this affect estimation? I will come to that.
It is required for any team to have a single backlog representing all work done by the team. A team’s backlog might have business stories, spikes, enablers, improvements, bugs and so on. It is seen in the industry that mature teams do not want to size Spikes, Bugs, Tasks, Enablers, Improvements etc and size only business stories. While it is good to get an idea of how much value a team is delivering, it is never easy for teams working on new and emerging products especially to plan a Sprint with this kind of sizing. I have seen teams struggling with planning and their predictability gets affected when they have a mix of items in their backlog. When there are many spikes, enablers, bugs etc in a Sprint, teams are unable to predict how many business stories they can complete along with the other items as other items are not sized. They might have a time box for some of the other items say, max 2 days for a spike and so on but still it becomes a challenge.
Then we thought why not size all items in the backlog? Initially there was some resistance as team members were having difficulty in sizing spikes, bugs and so on along with business stories. But when they looked at purely the complexity, unknown and volume of work, they were able to relatively size them too. When we size business stories also we consider the same factors and not the business value. Business value comes into picture for prioritization and among stories of equal priority, we may consider size as an additional factor for prioritization. That is another topic for another day.
So when we look at sizing, it may be better to size all work on hand which will definitely help in improved planning. Also some teams might get de-motivated if the value delivered is very low because many times they feel that enablers etc are also adding value indirectly. Then the next question comes how do we know how much value a team is delivering. We can always assign a value to each story and also any other work (say enablers) as needed and count them to know the value delivered by a team. I have seen this in some teams and they are quite comfortable doing it.
So this is something I am trying in some new teams I am starting to coach now and based on earlier experience with some teams, am hopeful that it might be useful to teams to become more predictable.
I am eager to hear from you all about your own experience in this aspect and please do share your thoughts.
–AN
