One of my biggest surprises when I first met the squads I where going to work with at Spotify was that none of them were using User Stories. At first I observed to see their alternative. Unfortunately there was none. Instead most of the work got done as big chunks of work (what I would tend to call Epics) that was sliced into a todo-list of tasks (named that way by the developers) and also divided according different platforms.
Squad focus on technical tasks
A typical board contained one or more business cases and lanes for each developer/platform with tasks that were executed upon. These big “busses” where on the board blocking other works for weeks, which of course meant there needed to exist one or more emergency lanes for all expedite work (in the long run, most work).
This is a setup that does not foster collaboration, focus on value and art-of-the-possible. From an agile fluence point of view I would say it is a way of working that does not even reach fluence level 1 (Christian and I will describe agile fluence in more depth in a follow up blog post). From my experience focusing on User Stories is a great way of fostering the above values, and reach fluence level 1.
With a multi step workshop process we helped our squads to start using User Stories and visualize the value flow. This blog post describes how we facilitated that transition.
Get retros rolling
The first step was obviously to get the squad members to be interested in doing a transition at al. Helping or pushing teams into a new way of working (jumping from one local optima to an unknown and only possibly better) is not always an easy task and it was partially very hard at Spotify (since everyone there “knows” that they are a world leading agile company and therefore do not need change [SIC!]).
Anyway, my normal way of tackling this is through retrospectives. A broken way of working will almost always surface during retrospectives, and open up the possibility to offer some workshop, seminar or training, on the topic. But to do that you need to have regular retrospectives, which the squads did not have. Starting having regular retrospectives was therefore step one.
A User Story workshop
I would guess the the squads viewed us as fairly pushy, but in the end all agreed to participate in one or more workshops around User Stories and visualization.
The first workshop was about establishing a common view on what a User Stories is and what good it might do. I tend to favour experience based learning. Starting a session with some thought provoking topic related exercise creates energy and anchoring. Debriefing the simulation moves you into the theoretical parts. A good exercise provides an outcome and experience you can later refer to. The best exercise I know of to start great discussions around User Stories is the “Draw according to requirements” simulation invented a couple of years ago by my colleague David Barnholdt (also included in the attached presentation).
The exercise let two groups create a painting under time pressure (make sure they are seated around a table) and then compare the paintings. The trick is that they have different requirements, one open ended and one extremely detailed (emulating both a traditional specification or a technical task based approach). What normally happens it that the group with the detailed specification get lost in the details, while the group with the open ended specification ends up with a much nicer (and more to the point) painting.
It normally fairly easy to go from this experience to the benefits of User Stories. The formula for a User Story is so easy, and most developers today knows it already, that nailing that is a walk in the park.
But then the hard part comes. How do we actually write User Stories, how do we slice our business cases into reasonably sized stories to work upon, and what is a reasonably size?
Practicing on actually writing User Stories is something I think is best done with a real backlog and in a real situation. As a coach I would say you are expected to participate in a number of backlog or story start meetings and help the participants formulate and slice stories. There is also some more formal aspects of User Stories, such as definition of done and the like. It’s good to cover these aspects, but they can also wait.
There are, however, four (4) absolutely fundamental thing that you will need to expose your participants to, since you will have to reference these again and again when helping the team writing good User Stories.
The first is that User Stories are actually meant to be a token of conversation, and not a document that can be handed of in silence between different actors, it’s called a story because it must be told. The open ended character of a story should foster dialog. And there is nothing wrong with actually capturing this ongoing dialog.
The second important thing is that User Stories almost always need and should be broken down into smaller parts, and that those parts should provide some kind of value. I simply love Jeff Pattons metaphor on how to divide a bigger bill into smaller ones, and that the ones you are actually executing on might not have an end user value in itself (a slices of one dollar bill) but should any way contain some value.
The third important thing is that value is not always end user value. When starting development value can also come from reducing risk. There are a number of risks you might want to reduce: technical risks, social risks, business risk. You should normally start with a set of stories that target those risks. I often call these stories spikes. They target different risk by driving a nail through all things involved, be it technical complexity or business uncertainties. These can and should also be expressed as user stories, with an expected outcome that can be followed up.
The fourth important thing is to combine an iterative and incremental approach to climb the value curve. When starting it’s important to work iteratively and try to paint the complete picture even if it does not end up in a releasable state. We do this to increase learning. Eventually, preferable after we have been able to deliver a releasable Minimum Viable Product, we can work more incrementally by adding small ready made features.
Follow the User Story
Next we had workshops on the flow of a User Story, from idea to usable product or feature. I usually start with 4 post-it notes of different sizes, a big, a medium, a small one and the really tiny ones. I place the big one to the left on the board and says: “Here we have a business idea. We do not really know the size, but it is probably bigger that a couple of weeks. Lets call it an Epic. Lets follow the what happens to the Epic from idea to delivery. What steps will it go through?”
Then I usually bring out the medium post-it and ask: “At what stage do we make sure we have written a number of User Stories covering the Epic?” This normally brings up a discussion about the collaboration between the team and the product owner. Who is responsible for breaking an Epic down, do we have regular meetings, what is a reasonable size?”
This is often a good opportunity to start a conversation about flow. It helps if the participants have experienced some kind of lean based simulation (such as the Name Game or the Lean Dot Game) where the importance of small batches, one-piece-flow and pull have been illustrated. We do not want our stories to be liked busses in a traffic jam. Instead we want small vehicles that can travel fast across the board. It is very important to get a buy in for this, and help the team reach a rule that says that stories bigger than a certain size are not allowed to enter the development part of the workflow. I illustrate this with a small post-it. It’s the big dollar bill that has become a one dollar, or even a teared dollar.
“What happens next? Do you need to do more?” Often people answers: we need task. I tend to say: “Yes, tasks is often good. It’s like a todo-list. They do not provide value by themselves, but are the steps we take to produce value”, and then I bring the super small post-its up. “But if your User Stories are small enough, you do not always need tasks. It is up to you”. We ended up preferring tasks at all my squads at Spotify.
By the end of a workshop like this you have hopefully established the concept of a story flowing from a big Epic over smaller User Stories, through a set of stages. You will probably also have a small set of explicit policies: what properties does a story need to have to be allowed to flow into the next stage.
A new Board for a new Way of Working
Introducing User Stories often means the existing board needs to be updated och re-done. This is often a fun practical exercise where I think it is important that the team itself make a layout they think is suitable for themselves. No board looked like the other when doing this at Spotify.
Great stuff, thanks for sharing!
Thanks! It’s easy to be a midget if you are standing on the shoulders of gigants 😉
//Peter
Nice one, something I imbue in my training as well. Your breakdown into the parts is really great as well. Not so much thinking about tasks is good. That could fall into a trap of silo-ed development.
Super useful. I particularly like the $ bill and Mona Lisa metaphors; they’re keepers for sure!