Home > Agile, Kanban, planning > The mandatory stuff

The mandatory stuff

When I have a story writing workshop or some other brainstorming activity, one important task is of course to learn what is really important. Since I’m in the mental moving from scrum to Kanban, this has become more than important. It is crucial.

So, these are my phases of a story writing seminar:

 

The objective

During this part, we discuss the overall objective of the project. What we’re doing and why. I try not only to explain what the customer wants but I want the team to really make the objective theirs. I want them to form their own Commander’s intent so they not only know what the objective is but also what it’s not. We don’t have time for nice to haves. Most of the time…

 

Brain storming stories

This can be divided into a number of separate parts. If it’s a new group or the developers are not fully aware of the business, this should start with the discussion of the different user groups or personas.

Then we move over to the brainstorming of stories. Presented with the objectives and the user types, everyone gets to write their own stories. A tips here is not to push the user story format. When you make it mandatory, people will debate you, but if you instead say that you want to know not only what but why and for whom and that this is an excellent form for that, you get more in a story format. Don’t be afraid to see developers and operations as users. Some stuff you need for these groups too. And writing stories with yourself as user type makes developers learn how to use the format.

 

Grouping stories

After everyone has written their stories, I usually send two or three team members to the whiteboard to group the stories. I let them decide on groups.

After that we say the stories out loud. We select the stories we need, sometimes write some more and some of the stories are discarded after we explain why this is not necessary.

 

Highest priority

I then get everyone to mark on each story if it’s mandatory or not. Everyone get’s their saying.

We then sit down and I pick up the stories which at least one person said was mandatory. I then ask the following question about each and every story:

– If we don’t do this, the project will be worthless and unsuccessful?

This will make the number of mandatory stories much much smaller. When I was more junior as a product owner/project manager I thought the mere asking if the story was mandatory was enough. But the important question is if the story makes the difference between success and failure.

If a story is still considered as mandatory we look at the objective. And I ask the question:

– So, how will this help us reach the objective(s)?

A number of stories will lose their status as mandatory right there and then.

What is the first thing to do?

The next phase is to understand what we need to know where to start. If you have multiple sub groups, you should ask each group what they want to start with. Now the team often remember The Other Stuff, as development and testing environment, setting up build scripts and all that so be prepared for some extra story writing.

When every sub group has identified what they want to start with, they must say if they are dependent on another group to start with their first task.

If the groups depend on each other, use The Theory of Constraints to specify the priority. With that I mean that you should try to optimize the usage of the bottleneck resources.

Is this it?

This is an exercise which should be done regularly. As long as you have stories, you can focus on the next most prioritized items but you will need to go through all phases many times during a long project

Advertisements
  1. 2009/09/11 at 6:03 am

    Hey Anna!

    Nice post. I think it would be fair to mention Mike Cohn’s two books User Stories Applied and Agile Estimating and Planning where these topics are elaborated in much detail.

    Also, I have a question for you: Why is it /you/ that explains what the customer wants? Why is it the /developers/ that brainstorm new stories? What was this agile thing again…? 😉

    • Anna Forss
      2009/09/11 at 6:08 am

      I thought everyone was tired of me promoting Mike Cohn.

      I failed to mentioned that business people and customer representatives also are included in the brainstorming of stories. In our case (mainstream leisure travel), the customer is represented by a number of actors in these sessions but since the problem for my organization until now has been that the developers have been excluded from these discussions, I perhaps stress their participation too hard. To have a successful user story brainstorming session, both need to be participating.

      Good point!

  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: