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.

Practices of an Agile Developer

I earlier reviewed my experience thus far with this book at http://johnragan.org/2009/11/12/practices-of-an-agile-developer/.  Now, I have finished reading it.

All in all, even though a lot of things weren’t new to me,  I would have to recommend this book.  I went through and summarized the contents in Evernote for later review, but I can’t share that with you (it would not be fair to Venkat)!  However, a couple of things did stand out for me:

  • Criticize Ideas, not People. Doing the opposite kills the cohesion of an Agile team in short order.
  • Invest in Your Team. We used to each study and present technologies or hold recurring group brown bags – what a difference it made!
  • Know When to Unlearn. Earlier I thought of the people I knew programming in C++ but still doing it as C. However, as I drove home listening to an old Pragmatic Programmer Podcast on Version Control with GIT by Travis Swicegood, I realized I had learned the GIT syntax for my GitHub account, but I was still using it as a substitute for Subversion as opposed to learning and embracing the GIT philosophy.  No wonder younger developers often use newer technologies more effectively because they are not encumbered with the older ways of thinking.  I have some more studying and unlearning to do it seems!
  • Communicate in Code. It seems we often code as if we are balancing a house of cards.  You coded a certain statement a certain way, but no one would never know why that way was important later on.  I have always (well, not always) strived to comment why I did things a certain way in these gotcha situations to help the next person come along.
  • Keep a Solutions Log. Why wasn’t I doing this earlier?!  This summer I started summarizing all the technical books I read in Evernote, but I will still not doing this for problems and solutions (until now).
  • Schedule Regular Face Time. Daily stand-up is not all that complicated, but doing it every day, at the same time, and keeping it short made a tremendous difference for previous teams I worked with.
  • Review Code. I was never a fan of this due to my earlier work on an SEI Level 5 environment on the Space Shuttle’s flight control software.  Lots of checklists, checking of the checklists, and so forth.  Between tools like FindBugs and PMD, as well as Peer Programming, I figured that was sufficient.  However, the latest research seems to show conclusively that this can really makes a huge difference.  I am currently unlearning my old opinion…

There are a number of other agile approaches covered in the book, with great ways to gauge how things are going and tips for implementing.  Hats off to Venkat!