Prioritizing User Stories

One of the most important survey results conducted by an important international organization, states that 64% of the functionalities included in software products are never or almost never used!
How come?!?
One way to avoid such a waste of resources, is to assign priorities to the user stories and to develop them starting from the highest.

 This post wants to address that 64% of features to be developed, which are never used by the final users once the product is deployed on production. After all, avoiding those features isn’t a way to reduce costs and time necessary to go live?

Let’s see how SCRUM faces to this issue.
As you probably know, the SCRUM framework provides three different roles: the team, the scrum master (SM) and the product owner (PO) (see URL). All of them are important. Maybe the team can be considered the most important, but for sure, SCRUM cannot work if any of those is missing.

This post is dedicated to the important role of the Product Owner and to one of its duties: prioritizing the features!

Once the gathering requirements phase is finished, the product owner should have in her hands a list of index/note cards in which are written the user stories.

The process of prioritization, must be conducted in order to:

  1. Maximize and accelerate the ROI
  2. Reduce risks

In order to maximize te ROI, the PO must have a clear understanding of what the customer wants in terms of: objectives, necessities, opportunities to reach, in one word, she must understand what is the actual Customer Business Value to gather.

Reducing risks, on the other hand, is primarily a matter of:

  • Remove any impediments
  • Give answers and explanations to any doubts or open points
  • Deepen, if necessary, user stories that are not clear
  • Execute as soon as possible any critical project activities

We can consider critical, an activity that will use a new technology not yet known to the team.
Or, furthermore, an activity that is one of the most important of the entire product, over which there are lot of expectations from the project stakeholders.

For the first case mentioned (new technology) is important to work on that feature as soon as possibile in order to “understand” the new technology and how to work with it. This will allow the team to capitalize the knowledge just acquired and will lower the risks.

Facing the second case (hot feature), it is again a matter of work quickly on it and to fast deliver it in order to receive, even here as soon as possible, feedback from the stakeholders.

Thus, it’s only a matter of assigning the right priorities, isnt’ it?! Yes but, how?

Actually, there are many methods available to achieve that goal, but the one I want to explore today, is the one that takes care of the customer business value and the risks associated to each feature, assigning to them an index (from 1 to 10 for example) in order to draw a point in a x/y graph.

This method is also mentioned in one of Mike Cohn’s books (Agile Estimating and Planning) that I strongly suggest to read.

So, let’s use Excel.

Create a new worksheet containing three columns: User story ID (or title), Business Value Index, Risk Index.

List all the user stories and for each one first assign a business value index: 1 for the lowest and 10 for the highest.
Higher values should be assigned to each activity that directly aims to one or more of the objectives to be achieved.
Lower values should be assigned to the activities not so important in achieving the goals like ancillary activites, maintenance or administrative activities, reports, etc.

Once a business value index is assigned for each feature, is time to provide risk indexes.
Higher values should be assigned to critical features like those that uses new technologies, those not well described or well understood, those that have  many interactions with external systems, those that will serve different typology of users and so on.
Lower values should be assigned to the remaining acitivities.

Now it’s time to create a graph, having excel plotting the points.

Now, compare the graph you obtained with the reference matrix above reported.

Well, it is time to start working and remember: the features never or almost never used, are the ones having a lower business value assigned; so, do them at the end and, furthermore, try to avoid those with an high risk associated!

1 commento

Other Links to this Post

  1. Acting as a zipper: here is the Product Owner. | Emiliano Soldi - Project Management Agile Blog — 11/11/2011 @ 14:51

RSS feed dei commenti a questo articolo. TrackBack URI

Lascia un commento


WordPress Themes