Strict Standards: EF_Custom_Status_Block_Editor_Compat and Block_Editor_Compatible define the same property ($ef_module) in the composition of EF_Custom_Status_Block_Editor_Compat. This might be incompatible, to improve maintainability consider using accessor methods in traits instead. Class was composed in /var/www/blog/wp-content/plugins/edit-flow/modules/custom-status/compat/block-editor.php on line 38
Measuring team velocity in User Stories -

Measuring team velocity in User Stories

Let’s consider a scrum team who is working together from enough time as to have reached their “performing” stage. And in this consideration, the term team includes the Product Owner. Let’s imagine this team is starting a new project, in the same technologies and in a business area they already know, so no specific complications. The product backlog is ready to start being groomed . As usual, the Product Owner must provide a date when the product can be delivered. Here starts the story.

Classically, we would say our team must start breaking epics in user stories and estimate them. With this total amount of story points, and as we know our team’s average speed, it would not be difficult to estimate when the product could be ready. Please, note:

  • An estimation is not a commitment ! I mean, the team estimates the product COULD be ready by that day, but it doesn’t mean that our company defines the release date exactly on the same day! What about giving us the chance to have underestimated the scope , or having any unforeseen event?

Wait, here comes the magic ( and possibly the debate )

As a mature team, our product owner has experience breaking epics in user stories, and she knows exactly the kind of user stories the team expects to work on. They have already done this before, working in a backlog , writing user stories… Our team already realized that most of the user stories they work on have a similar size, they could group their user stories by sizes, and they would find out that it looks like a Gaussian function . Wow , what a surprise! ( or not! )

What does this mean? what are the implications? Well, you smart reader will have probably figured it out : In order to define a possible date, we don’t even need to estimate each user story. We might consider all our user stories to be as big as the “peak” of our normal distribution. Therefore, we would be saving a huge effort of estimating every user story, and actually become even more productive by having more time to develop software.

Even if you, Product Owner, might feel fear of not having things under control following this approach, I have to say that many mature teams already realized and started applying this approach.

What are your thoughts?


Leave a comment

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.