User Stories from the trenches

I couldn’t resist the topic. But for the record, credits to Henrik Kniberg for the “…from the trenches”-bit :-).

The past few weeks have been hectic, and I haven’t really had the time to post anything new in a while. The reason is that I’ve been in a phase here where we’re ramping up a project and I have been heavily involved in trying to form an initial backlog with an initial set of reasonably meaningful User Stories for that project. I.e.: we’ve been involved in getting a (very large) project “vision” down into a set of stories.

Our traditional method for this was to have the Product Manager (Customer) produce a written description of each feature that he wanted, and then he would hand that over to the Development Department where we (“we” being the team and the Scrum Product Owner: as you may know we use the somewhat controversial “Product Owner Proxy” construction in our organization) would take ownership of that written “spec” and break it down into User Stories that were prioritized and later estimated and delivered in priority order.

My problem with that approach was (and is) that the Product Manager usually (for whatever reason) spent alot of time writing these “functionality specs”.
I have felt that this goes against my core attitude/rule-of-thumb “Never document more than that you have to ask to understand” and that it is pretty "un-scrum". I’ve been wanting to find a better and more Agile way of moving from “The vision inside the head of the Product Manager” to “Something that the team understands, which can be prioritized and brought into the Sprint Planning meetings”.

In this case, with this development project being such a large one (a new product, with so many functions), it would simply have been an overwhelming task for the Product Manager to rely on our traditioinal approach and write all those "function specs" up front – at least considering the usual level of detail in those spec documents.

My idea was to skip the “detail specification” step alltogether and jump straight from the vision to User Stories, and thereby save time by having the Product Manager produce User Stories directly which later could be prioritized and further broken down. This would somehow force the Product Manager to skip details and thus not try to think of everything up front. Oh, and of course, we’d be forced to rely much more on face-to-face communication between the team and the Product Manager, which would be great: “two people by a whiteboard” is always a many times more efficient method of transferring information than by document, right?

So that was the plan, and this is what I have been struggling with for the past weeks (plus celebrating Christmas and New Year :-)).

I can’t say that it went great maybe, but I'm still pretty satisfied with the result so far. Anyway, I wanted to take this opportunity to really reflect over how things went and try to gather my own thoughts about it and nail down some lessons.

Here are some of the challenges with the past few weeks;

• I needed to find a way for the Product Manager to “empty his head” into something that could be used as basis for formulating some fundamental stories.
• I needed the Product Manager to understand what User Stories are and why they should be formulated in a certain way, what level of detail they should have, and so on.
• I needed to find a way – a method and tool – to document the User Stories which would fit nicely with the tools we use further down the road: we use the Backlog Manager tool that I have made available for download on this blog in a separate post.

I approached this by introducing MindJet MindManager to the Product Manager. I know there are open source and other free alternatives out there too, but I haven’t tried any of them myself.

I use MindManager for many different things, and I find it great for emptying my head down into symbols, boxes, notes and relations. So the idea was that it could be used by the Product Manager too, to get the rough set of functions and other thoughts and notes down into a visible map. That map could hopefully then be used to look at to formulate User Stories; e.g. by studying a subtree and all the nodes there to remember what needs to be covered by the backlog.

The map ended up looking something like this, but much bigger (the map below is just a very small dummy example, obviously):

In retrospect, we experienced a few major drawbacks with this method of using a mindmap to describe the vision of the project and have the Product Manager use it as basis for formulating stories;

1. Coping with keeping the map up-to-date with the stories: as stories are formulated, iterated, thought about, discussed and reformulated, after a while there are changes in the perception of how things are supposed to work. We failed at keeping the map up-to-date throughout this process. After a while the list of user stories conveyed a different picture than the map. However, I think it might be ok that the map is a “consumable” that can’t be trusted after a while; it’s just one tool used along the way and is not really an artifact by itself.
2. Ones stories were formulated, they ended up being too small. The initial backlog ended up containing much too many stories and each story gave just a too fragmented view of what should be delivered. The symptom of this was that it was very hard for the team to grasp the project as a whole, even with a lot of communication with the PM. The breakdown done was simply much too detailed and too early.

I think my main lesson here is to try to get the Product Manager to just summarize each desired feature as a Theme or Epic (see separate blog post), rather than in a whole bunch of small stories. If there are important details about the function that the Product Manager wants to mention he should write keywords as “notes“ to the story, and not try to write each as a separate story.

Also if there are things in the Epic/Theme which can be given different priorities, obviously those can be broken out as separate Themes/Epics. The ambition should however be to not break everything down in detail.
The finer breakdown, into “ready-ready” (see separate blog post) User Stories should be done by the team in cooperation with the Product Manager – not by the Product Manager himself.

So to summarize on the lessons learned so far:

• Get the Product Manager to use a mindmap to empty his head into, with regard to a certain vision of function(s).
• Get the Product Manager to look at the map and its subtrees and use that to write Themes (or Epics), formulated as User Stories (“As a I want to so that .”.
• Get the Product Manager to write those Themes/Epics in the same or similar tool that you will be working with in Development (e.g. if you can, directly into an empty Backlog Manager excel, if that’s the format you’re using).
• When the Product Manager feels he’s covered the most obvious and/or most important Themes/Epics, bring in the team. Let the team and the Product Manager together work on the finer breakdown – of the most important Themes/Epics.
• Talk alot about the Themes/Epics: between Product Manager and team. Let the Product Manager describe each Theme, if you have an updated mindmap you can use that as basis for a presentation about each, as part of the breakdown process.
  
• Break down the Themes/Epics one by one, and work face-to-face. Even if it takes the PM and the team a long time, I have a feeling that it is time saved in the end: because the team will get an excellent view of the backlog. A challenge here is to heavily moderate discussions about how to build the stuff: solutions shouldn’t be discussed at this point. That’s done when the stories enter the sprints.
• Don’t attempt to break every Theme/Epic down into smaller stories from day one. Make sure they’re explained and moved into the product backlog, but break them down in priority order: start with the most important ones. Leave the lower priority Themes/Epics for later sessions. Just because they’re big it doesn’t mean that you can’t estimate them. Remember: rather roughly right than precisely wrong.
• Come back to the bachy hklog after every sprint and review the Themes/Epics and let the team and the PM break them down once they surface in the backlog.

Here is an example of a subtree which could be used as basis for writing a Theme and later for discussing around as part of breaking it down into smaller stories;

Example of a Theme for the above subtree: "As a Administrator I want to be able to manage users so that I can control who has access to what."

Once the team and the Product Manager break it down together, they'd probably end up with something like the following user stories:

• As an Administrator I want to be able to add new users to the system so that each user can have his own personal account to login with.
  
• As an Administrator I want to be able to search for users and and be able to sort the resulting list in various ways so that it maximally easy to find what I'm looking for.
• As an Administrator I want to be able to Clone an existing user so that I create a new one with the identical data pre-filled so that I don't have to retype everything.
• ...and so on.

We’re still not done here and have some distance to go before we can say that the backlog is in an “OK” shape. I’ll revise this post and/or make additional posts with more thoughts and experiences as we go along.

Oh, by he way. I always appreciate feedback about your experiences. If you have any clever ideas or thoughts about this or how you work with it in your organization, please leave me some comments.