We recently finished a scrum sprint; during the sprint review the technical team gave a demonstration, to senior business owners, of the newly developed functionality and bug fixes they had done during the sprint. It was noted at the sprint retrospective and subsequent discussions, that followed, that the demonstration gave equal weighting in terms of the time spent demonstrating each user story. However some stories were minor bug fixes while others where major enhancements to the site's home page. The question is how does the technical team know how much time to spend demonstrating each user story?One way would be to demonstrate the stories in priority order. However this would just give an order for the demo and not a give any indication on how much time should be spent. I believe one way would be to introduce an estimated business value to each story refer to Measuring business value with metrics for more details. The technical team are quite used to using Fibonacci numbers (1, 2, 3, 5, 8, 13, 21 ...) to estimate the complexity of a given user story and the product owner and other business stakeholders are accustomed to watching the technical team use the poker cards to vote on the complexity of a given backlog item and then witnessing the team member who gave the highest vote discuss with the team member who gave the lowest vote the reasons why they voted in that particular way. The team then votes again based on the new information they have heard.
A way forward would be for the business stakeholders to go through a similar exercise. The business value would depend on the type of product you are developing. For community website the following could be considered: Search engine optimisation (SEO) value; improvement in usability or user engagement; third party sponsorship generating direct revenue; improvement to backend editorial systems that increase efficiency and through put; automating processes for editorial staff….
Once a business Fibonacci has been given it will be a simple exercise for those demonstrating newly developed functionality and bug fixes to give the correct weighting in terms of time to each user story – thus keeping the review fresh and relevant and ensuring that business stakeholders stay engaged through the session.
However there is a much better reason for estimating business value for each backlog item – it not only helps with setting priorities but can be used to measure the amount of value and therefore ROI for each sprint and ultimately be used to calculate business velocity in a similar way that the scrum master calculates technical velocity for a team or individual. Estiamting business velocity, (refer to Understanding your Velocity for an explanationon on velocity) will also give the product manager and product owner a high level indication on the amount of business value that a team are able to generate for each product roadmap.
No comments:
Post a Comment