Facilitating the Elephant Carpaccio Exercise

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).

The exercise is about creating a quoting application which includes different markets, tax and discounts. If you have not done this before your initial slices will probably be pretty large. The aha moment is when you realize how SMALL you can actually make them. You can can dry run this exercise by only creating and discussing the backlog. It’s also very friendly to actually do it for real by programing the application; even excel can be used to do that.

Henrik Kniberg has written an excellent guide on how to facilitate this exercise. Here’s my slides based on that presentation to make it a little bit easier to remember and run it in a classroom.

Getting High on Your Own Supply

shared-knowledge

Back in undergraduate school I had an artsy roommate who quickly dropped any intention of attending classes. Soon thereafter he picked up a line cook job at the local diner and took on a nocturnal lifestyle. That lifestyle led to a whole new set of friends who quickly helped him develop a recreational drug habit. To support his new found hobby, my roommate began dealing to his new found comrades and their acquaintances. The temptation of having all of that product around him turned out to be too much though and, soon enough, he was consuming more than he was selling leaving him increasingly in debt to his suppliers. This culminated in a day I’ll never forget. I had to take him to the pawn shop so he could trade his car (his last possession) for cash to get out of that debt. We rode home on the back of my motorcycle (which became our only means of transportation for the duration of our cohabitation). read more »

WIP and Priorities – how to get fast and focused!

Many common organizational problems can be traced down to management of Priorities and WIP (work in progress). Doing this well at all levels in an organization can make a huge difference! I’ve experimented quite a lot with this, here are some practical guidelines:

WIP = Work In Progress = stuff that we have started and not yet finished, stuff that takes up our bandwidth, blocks up resources, etc.. Even things that are blocked or waiting are WIP.

“As a, I want, So that” Considered Harmful

If you are working on an agile project, it is almost certain that you are using Stories to describe your backlog of work. It is another near-certainty that if you are using Stories, you write them down using this format:

As a <user or stakeholder type>
I want <some software feature>
So that <some business value>”

As someone who cares about the state of agile practice, I want to offer some alternatives, so that agile teams remember that the point of the story is in the telling, not the template. The shared understanding comes from the conversation, not the card. By offering you different ways to ‘tell’ the story in its short written form, I hope you will be able to re-ignite a greater level of meaning, interest and engagement in your team’s discussions about the work they are doing to build great software that matters to people.

read more »

Spotify Engineering Culture (part 2)

Here’s part 2 of the short animated video describing Spotify’s engineering culture (also posted on Spotify’s blog). Check out part 1 first if you haven’t already seen it!

This is a journey in progress, not a journey completed, so the video is somewhere between “How Things Are Today” and “How We Want Things To Be”.

Here’s the whole drawing:
Spotify-Engineering-Culture-Part2

(Tools used: Art Rage, Wacom Intuos 5 drawing tablet, and ScreenFlow)

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.

read more »

Video – product development without the product owner

Crisp’s Youtube channel has made a new release – introducing Concepts.

Concepts is used to let passionate people run with ideas, a different approach than that of traditional product ownership. If you do use in conjunction with a product owner, it allows that person to spend more time on the field with customers.

Ps: The mastermind behind the illustrations -> Jimmy Janlén!

More on concepts: crisp.se/concepts

Try out concepts at The Product Owner Survival Camp, 3-4 Nov

Cheers

/Mattias