User Stories Applied: For Agile Software Development by Mike Cohn

So, I have been busy the last number of weeks rolling out Scrum along with complementary Agile practices to a new team.  I saw this book, thumbed through it, and felt it would help me address some of the challenges I saw down the road.  I put a brown bag together that morning, and then off we went on planning our new release!

I (as Scrum Master) had already worked with the PM (e.g., Product Owner) to prioritize the features. We did not have them in user story format yet, but that was okay as we had a set of one to two sentence feature descriptions.

How could that possibly be okay?  Well, the real purpose of user stories is not so much to fully document the desired functionality but to serve as placeholders to drive face to face discussions between developers and PM.  From the Agile Manifesto:  “Individuals and Interactions over processes and tools”.  With only a few sentences, you have to talk.  You can add a few notes and assumptions, but I like the general advice about how if your user story notecard is not large enough to hold all the information, try a smaller notecard.

In other companies I had worked unsuccessfully with PM’s trying to leverage Use Cases as the new solution.  They were taking too long to write, the PM’s did not have time to do it, and often the PM’s would write use cases based upon the UI design they had in mind for a feature as opposed to addressing the harder task of writing it based upon users’ needs.  User stories force you to address the latter.

Make no mistake, designing features based upon the users’ real needs is challenging, hard, and painful.  The work we spent the last 1.5 days was much harder than the coding I expect to be doing in support of these features – I would go home exhausted!

First, we gathered the developers, QA and Doc together.  PM and UX served as the customer representatives in the Estimating Game.  We have our upcoming release, and needed to get a rough estimate for each feature for initial release planning and re-prioritization based upon effort.

The PM would grab the next highest priority user story (feature) and present it.  Then, all of us would ask a number of questions about the feature.  After that, developers would write their estimates down, and then they would reveal all at once.  The estimates would often differ wildly, so the developers would discuss their rationale.  We would repeat a couple times and come to consensus.  QA and Doc would give their estimates, and then it was tracked.

The meeting went well at first, but then started to bog down as the PM had to leave early and we were missing the business value.  So, for our next meeting, I asked the PM to convert each feature to an epic user story on the fly.  It was epic because it was too large in term of what would need to be done, and required being broken down into multiple user stories.

We would then raise a number of questions, continue to take the initial user story and break it down into other user stories based upon user end-to-end functionality.  We all worked extra hard to keep UI out of the stories, and to use implementation only as examples to flesh out desired behavior.  What was particularly helpful was using this format from the book:

I (as role) want to be able to do (feature) because (business value)

Since our PM is busy, I decided to use the meetings with him to focus on user stories, and then have separate meetings with the implementers to play the estimating game (and later sync back together).

Now that we had this, it was much easier for the developers to work with UX on how to approach the feature, and how to design it at a high-level for estimation in separate sessions (we’ll pull the PM back in to these as well as his time frees up).

For one user story, a developer pointed out that the user story presented a solution for solving a problem rather than stating the problem that needed to be solved.  It was subtle, but by being able to back the user story up to the more abstract representation of the problem to be solved, we can design a much better feature.

In general, it takes longer for the development team to complete the estimating game for the user stories associated with each feature than it does to work with PM to break them up.

Initially, I had hoped to approach the features planned for the release in a Just in Time (JIT) approach on each Sprint, but given dependencies between the features and user stories, it was important to spend a few days up front establishing the user stories associated with the release, even if all may not end up making it.

It was painful, but necessary and effective.  Sitting down together and talking through these features was highly effective.  We have a much better understanding of how to design the features in a way that will best meet the end user’s needs.  The Developers picked up a much deeper domain knowledge of the problems our customers are facing, as well as an increased respect for the PM (as did I).  I think the PM (by participating in the initial estimating game) had a better understanding of why the estimates were as high as they were.  All in all, we are much better positioned for success.


One thought on “User Stories Applied: For Agile Software Development by Mike Cohn

  1. Pingback: Revue du livre : User Story Applied de Mike Cohn « Agile pour tous

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s