Driving Business Value in Agile Projects

Being a project manager running Agile/SCRUM projects is a difficult job, specially when it comes to the meetings with stakeholders where you are asked the most painful yet most important questions on measuring value to the business. Often we feel unarmed and unprepared while answering these types of questions

In fact, another pressing issue that a project manager have to always deal with in such projects is what I call, "the triangle of truth". It takes a a lot of skills and experience to be able to accurately estimate, balance, analyse and refine the complexity, effort and resource requirements for individual user stories, epics and sprints. As much as I would like to elaborate more on this topic, I want to stop here and re-focus back on the issue of business value. I will perhaps publish a separate article on this topic later.

So, lets get back to the question of how to derive, report and communicate the value of the user stories and the actual work done in a sprint to the stakeholders? Well it is a challenging thing to achieve, and there are a number of different ways proposed by the Agile/SCRUM gurus, to solve this problem. I have tried and tested most of these approaches, and have come up with my own model, that have really worked well in most of my projects.

Step 1 : Focus on the sprint, not the entire project backlog - Identify a small subset of the user stories to work with on the estimates. The key point to note here is that, the entire concept of Agile development is to not look at the project as a single backlog (unlike in a waterfall model), yet we often undermine this, and try to estimate our story points, and or time estimates keeping the entire backlog in focus. An ideal approach would be to always take a subset of the product backlog, ideally less than or equal to 10 user stories, and then perform the estimates within this subset. As an example, lets assume that the entire project / product backlog contain 50 user stories, then while planning your first sprint, pick 10 user stories based on their magnitude of dependencies (the ones on which most stories depend on), and then perform the estimation within this subset of 10 stories

Step 2 : Estimate in points - Use story points for complexity estimates, and use value points for value estimates. Often online project management tools, lacks out-of-the-box fields to address value. Most likely, the closest they come to value is through "priority" buckets, and identifying user stories into low, moderate, high or very high priorities. In my experience and research, I find priority buckets as highly inadequate attribute to justify value. By dumping the generic priority buckets, and instead using a custom value points attribute to the user story is highly beneficial

Step 3 : Identify a common point scale - Use a common point scale for estimating both the complexity (in story points), as well as value (in value points). I prefer using the fibonacci sequence for the estimation, however you can choose any preferred numbering scheme. As an example, to estimate value and complexity out of the 10 user stories we picked in previous step, assign each of these stories with points out of 1, 2, 3, 5, 8, 13, 21, 34, 55, 89 (the 10 numbers in the fibonacci sequence)

Step 4 : Know your role before starting estimation- Value points assignments should be performed by the product owner / project manager, with inputs from the stake holders before the sprint planning meeting. Story points assignments should be done by the scrum master / team manager with inputs from the development / delivery team during the sprint planning meeting

Step 5 : Always do relative, and mutually exclusive estimation - While performing value, and or complexity estimations, always stay within the chosen subset (shortlist) of the user stories. The best approach is to assign the highest number in the scale to the most complex story (for story points), and likewise to the most valuable story (for the value points). Then assign the smallest number to the least complex story, and least valuable story respectively. The rest of the numbers in the point scale should be assigned thereafter, while keeping their value/complexity in reference to the highest and the lowest. As an example, in a chosen subset of 10 stories, assign number 89 to the most complex of the 10 (under story points), and then assign number 89 to most valuable of the 10 (under value points), similarly assign number 1 to the least complex story, and to the least valuable story respectively. Note: The key is not to assign the same number again for any story in the list i.e. you should not have 2 stories with number 89 as their value point, or 2 stories with 1 as their story point (keep them mutually exclusive within the chosen subset)

Step 6 : Identify the value index of the story - Once you have the value points, and the story points for a user story a simple calculation can derive its value index i.e.

Value Index (of a story) = Assigned Value Points / Assigned Story Points

A story with a higher index shall result in bringing more value to the sprint, than a story with a lower index.

Step 7 : Create your "value optimised" sprint backlog - Once you know what value a story carry, you can easily choose the top value index user stories from the list of 10, and include them in your sprint backlog. A general rule of thumb is, to pick the leftover stories from previous sprints (first) in your sprint backlog, and thereafter if there is room for more, create your shortlist of 10 stories, and perform their valuation as stated above. Now, the top value index stories from this list, should fill the slots on your sprint backlog for the new sprint

Step 8 : Produce your reports - Just divide the total value points burned in the sprint, with the total story points burned, to get the sprint value index of the sprint. Since the valuation of the user stories was performed with stakeholder's feedback, it is now very easy to prove, and justify the value that was generated as a result of burning down of the story points in that sprint

Sprint Value Index = Total Value Points (from all user stories in the sprint) / Total Story Points (from all user stories in the sprint)

In conclusion to this article, I would like to emphasise that, there is no right way or wrong way of value justification in an Agile project, and in essence, it is all about the flexibility of an Agile methodology, that ultimately drives efficiency in reporting!