Continue reading: Let the User Story Flow

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.

Continue reading

Continue reading: Product Owner’s Product and Project Board

Product Owner’s Product and Project Board

The team has its Scrum board as an information radiator. It is an excellent way of getting an overview of the sprint. But what about us, the product owners, don’t we need that too? Of course we do, we too have a need for an overview of our work and to radiate information. The stakeholders pass by and ask “what’s in next sprint”, “when will we migrate”. We’d like to just answer with a light gesture towards the wall. It is all there for everyone to see.

Let me tell you how our project owner board works, as an example.Continue reading