“On my current project, I am getting my first exposure to User Stories. (As a..I want..So that.) With so many stories, I am wondering about managing them so that future analysts will a body of documentation to reference. Right now, we have no structure, so the list of stories grows with no real way to search them. We seem to be OK with relying on memory, and I see this lack of structure as a project risk. Any organizing suggestions? “
I am assuming that your current Product Backlog has following fields:
- User Story Title – Small title for the User Story that helps you to identify it quickly
- Priority – Numbered Priority for the User Story. I prefer to have the Product Backlog ordered by this field.
- Points – Story Points for the story
- Status – The current status of the Story
As you mentioned, this is manageable when you start the project, however it gets more and more difficult to manage as the list grows. Consistently grooming the product backlog is very important. What I have found to be very useful is to add some more identifiers for each of these fields. This provides more control over the list.
Let’s look at few examples.
Severity (or you can call it Priority Group):
Values – Critical, High, Medium and Low
I use Severity with Priority to keep the focus on high priority user stories. Adding stories is a continuous process, and it may not be feasible to assign a priority as soon as you add a story. At the time of adding a new Story, I ensure that I assign a value for Severity even if I am not able to assign a Priority. If I am not able to assign a Priority then I just use 999 to identify that a priority needs to be assigned later. (Yet to cross 1000 in any single project.) Every week, we have a priority meeting where we sort the Product Backlog by Severity and then by Priority. This gives me a good starting point to concentrate on the Criticals and Highs. In most of the meetings we run out of time before we reach the mediums and lows and only look at these when they become Critical or High.
It is very important to clearly define and explain the values for Severity and ensure that it is used correctly. We generally have a product milestone of 4 months. Each milestone is defined as to what we want to achieve in that timeframe. Let’s say, for an e-shopping site the first milestone may be that customers can register and browse the list of items but cannot order the items. For the first milestone each story will be categorized as per this goal. So Customer registration form will be Critical but Credit Card payment will be low.
Story Group is linked to Story Title and helped me in grouping the stories. For example, some of the Story Groups for e-Shopping site can be Customer, Products, Orders, Order Fulfillment and Reports.
Story Groups helped me to look at the product backlog from a different perspective. Generally we work with different business groups who were focused on a certain aspect of the application only. At times, it became important to filter a product list and evaluate what are we left with in a particular group and tweak the priority of the stories accordingly. Though our eyes are always set on the milestone but it was important to focus on parts of the application to ensure we are not missing anything. One of the interesting outcomes was that we identified some duplicates and were able to weed them out.
We also ended up creating reports for the executive management by Story Groups which gave “just enough” insight to them.
When we started our Scrum Project, we started with basic statuses of Not Started, In Progress and Done. However, we realized the need to break it down a little further to provide more insight on where it stands. That helped us identify bottlenecks early enough to avoid undesirable impact on the team velocity. The decision to break it into different statuses is very dependent on the team structure and the processes followed. I don’t recommend breaking down the statuses if they don’t add value. The idea behind Scrum is to keep the process overhead as lean as possible.
As an example, we broke the statuses to: Not Started, Requirements In Progress, Requirements Done, Dev In Progress, Dev Done, UAT In Progress, Done
We also added dates for these Statuses. These were formula driven and were auto-populated as soon as we changed the Status. It is nothing very fancy and we used simple Excel formulas to manage the Product backlog.
The dates were mostly used for tracking and analyzing the turnaround time for various activities. I remember, at one point it helped us to clearly show that the UAT was not keeping up with the development and could cause delay in the final release. This helped us to get necessary executive attention on the issue.
My overall recommendation will be to stick to basic structure as far as possible and only add these or any other fields only if they make it easier to manage the list. Don’t add all of the fields in one go, add them one by one and see if you need the others or not. Only add more fields if you think they will add more value. Also, don’t shy away from getting rid of them if they are not useful anymore.
>>Read Some Related Articles
>> Learn More About Agile Requirements
Check out the Agile Track of Crafting Better Requirements, a virtual, instructor-led course that will also earn you 21 PDs or CDUs. You’ll learn about how to create a product backlog, turn stakeholder needs and wants into user stories, and create acceptance criteria to support testing.