One of the best exercises I know of on how to learn and practice User Story slicing techniques is the so called Elephant Carpaccio exercise. At Spotify it is something of a staple as it it is (often) used when introducing new employees (now a days). Facilitating the Elephant carpaccio exercise from Peter Antman The
Continue reading
Let the User Story Flow
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.
Lean Canvas – an hypotheses board
As so many others I’m inspired by the book Lean Startup. The idea of experimenting with your business model and deliver just the bare stuff needed to validate (or actually try to refute) your business hypothesis is so enticing. But how do you do that when you are one of 50 or 100 teams? How do you do that when the teams are not even using User Stories? How do you do that when daily work is done on a Kanban board only showing tasks?
One part of a possible solution is to find a way of visualizing the business case. A popular approach has become setting up a business board, often called a Lean Canvas. I wanted to try something like that. But going trough all the different variants I could find, no one was good enough in itself. I wanted to get the same feeling as with User Stories: a simple formula that everyone can understand and use as soon as the formula is presented.
Steve Bockmans team estimation
Estimation of the effort to implement and deliver a set of functionality is an important but not always the most fun part of product development. Estimations are done at different detail levels during the project, for example the high level story estimation and the low level task estimation. It is a few years since I did task estimation; many times it is a waste of time doing low level estimations, so in the following text I will describe a technique that I like when estimating the user stories.
The Product Owner team
In my opinion, the Product Owner (PO) role is the most demanding one in Scrum, since the PO needs to have so many talents and you rarely find all of them in one single person, so in my current team we formed a PO team instead.
Continue reading