Friday, September 4, 2009

Managing user stories in enterprise environment

In this blog, I want to take you through a user story example, the challenges with managing user stories in enterprise environment, and an approach to manage user stories.

Managing user stories in an enterprise environment can be challenging. The challenge comes from the fact that Product Manager, Product Owner and Scrum team have different expectations on how stories should be defined. Let's take a simple example - Product Manager writes a story - "As a Bank of America debit card holder, I would like to withdraw money from the ATM, so that I can make cash payments". From the product manager's perspective, who is a customer facing representative, this is a very well written story. This story is a value added feature that is marketable and billable to customer. From the scrum team's perspective, this is an epic, as it is too big to be scheduled in one iteration. Scrum teams like to see stories that can be estimated correctly and scheduled in one iteration.

The epic, sometimes also called themes that product manager writes, needs to be massaged further by decomposing them into smaller stories. The breakdown has to be granular enough with enough details for the scrum team to start planning their iteration. The scrum team gets together with product manager and interviews him for additional information. Some questions that the team might ask are - How does the user interface look like for your story? Will the customer scan or swipe the card? What information does the customer have to enter for authentication? How should the system respond if the customer enters wrong password the first time? How should the system respond if the customer enters incorrect password 3 times in a row? What is the limit on the amount of cash that can be withdrawn? And so on..

The answers to most of the questions will eventually turn into stories. Some of these stories will be granular enough to be scheduled in an iteration and some might turn out to be epics, that would need further breakdown. The point to be noted is, there is a gap between how product manager defines a story and what the scrum team expects, and this needs to be tied together somehow.

The above example just involves one product manager and one scrum team. Let's kick it up a notch and make things a bit more complicated. Now imagine an enterprise group that is building a suite of products with common infrastructure components. This enterprise  group would normally have multiple product owners, over 15 teams split as feature and component scrum teams , and most likely will be geographically distributed. The challenge here is to manage a common backlog, each scrum team's backlog, ensure all backlogs are in prioritized order, manage dependencies between different scrum teams, and tie epics (common backlog) to granular stories (Scrum team's backlog) and vice versa, etc..

So the question is how should user stories be managed in an enterprise environment?  

First, there should be ONE common prioritized product backlog enumerating all epics. These epics should be value-add features that the customer cares for. This list should also give the vision and direction to the scrum teams to align on common deliverables.

Second, A "Work In Progress"(WIP) limit of no more than 2 to 3 epics at a time should be setup (a concept I learnt from my friend Mike Cottmeyer).WIP enforces that the entire org is focused on first few epics. This also makes certain that teams are not writing code, that other teams aren't ready to consume yet.

Third, epics should be decomposed into granular stories and linked together via excel spreadsheet or tools like Rally or VersionOne for tracking purposes e.g. epic1 -- story1, story2, story3,.. . 

Fourth, the decomposed stories should then be transferred to each scrum team's backlog. It should be ensured that each team's backlog is always in prioritized order with enough details for scrum teams to plan their iteration.

The above steps can be tied together through the "Enterprise Scrum - A tiered approach" and "Enterprise scrum - the tiered approach (implementation)" that I discussed in my earlier blog. Remember, User stories are the heartbeat of agile development. The health of the product depends on how well the user stories are written, groomed and managed.

1 comments:

Mike Cohn said...

Nice posting, Hiren. The only thing I'd clarify is that an epic should be split into smaller stories only when the additional detail is needed. A lot of teams rush to do this and there do it too early.

Post a Comment