Scrum on One Page

This drawing is part of a Leanpub book: https://leanpub.com/agileplanet. If you like it, you might want to have a look at the book, too.

References:

• The official Scrum Guide
• "Agile Project Management with Scrum" - Ken Schwaber
• Agile Atlas on Scrum (Scrum Alliance)
• Jeff Sutherland's blog

A Story Mapping Workshop

Last Monday, I facilitated a workshop on Story Mapping at Agile Monday Nuremberg. I got some positive feedback on that workshop and thus, I will share the format and materials here for anybody interested.

Materials

• Slides for introduction (you can find my slides here)
• Flip chart paper or some other kind of wallpaper for every group
• 2-3 fine liner for every group
• Sticky notes

Execution

Keep the presentation short

1. Introduce Story Mapping in 5-10 minutes using just one or two slides.
2. Let people split into groups of at most five people per group and brainstorm what app they want to "build". (5 min)
3. Next, the groups will write the key activities for their app. (10 min)
4. After activities are written, every group thinks about the tasks needed for the activities. (10 min)
5. The next minutes will be used, to plan for a first release of the app. (5 min)
6. Let every group present their result, i.e. the app and the first planned release to the whole group. (3 min / group)

Duration: The whole exercise will take approximately 90 minutes, depending on the number of groups.

Three things, you should bear in mind as facilitator:

Participants working on tasks for their app

• Try to keep the introduction as short as possible. People will learn how to create the maps by doing it and speaking about the result to others.
• Set strict timeboxes, to help people focus on the current task.
• Encourage people, to try to explain their idea using their map inside their group, before they present it to the whole group. If they can explain it easily, this is a good indicator for a good Story Map.

Bottom Line

Some results of our Story Mapping workshop

The take home message of this workshop will be: Story Maps are a really simple tool and make it much easier to communicate to various kinds of stakeholders about your application and key goals.

Feel free to use this format and material for your workshops on Story Mapping. I would be grateful, if you leave comments or any other feedback and share your improvements on this.

Story Mapping on One Page

Impact Mapping on One Page

Trivia from the Scrum Guide

I just re-read the current Scrum Guide and I always wonder how things, that are very clearly expressed in this simple document are still frequently discussed, or not known...

I tweeted some of those trivial items and will bundle them here:

#Trivia from the #Scrum Guide: "For the Product Owner to succeed, the entire organization must respect his or her decisions."

— Fabian Schiller (@fabianschiller) October 20, 2013

#Trivia from #Scrum Guide: "No one tells the Development Team how to turn Product Backlog into […] potentially releasable functionality."

— Fabian Schiller (@fabianschiller) October 20, 2013

#Trivia from #Scrum Guide: "The number of items selected from the Product Backlog is solely up to the Development Team."

— Fabian Schiller (@fabianschiller) October 20, 2013

"The Product Backlog is an ordered list of everything that might be needed in the product and is the single source of requirements […]"

— Fabian Schiller (@fabianschiller) October 20, 2013

#Trivia from #Scrum Guide: "When a Product Backlog item […] is described as 'Done', everybody must understand what 'Done' means."

— Fabian Schiller (@fabianschiller) October 20, 2013

#Trivia from #Scrum Guide: "[…] what 'Done' means […] varies significantly per Scrum Team […]"

— Fabian Schiller (@fabianschiller) October 20, 2013

#Scrum Guide: "If there are multiple Scrum Teams working on the system […] development teams must mutually define the definition of 'Done'."

— Fabian Schiller (@fabianschiller) October 20, 2013

Lean Startup Experiment - Day 3

Day 3 of our experiment is over. It was a day full of work and (from our point of view) huge progress on the project. We improved the layout massively and included some hints on the page about our intentions. We got the large image view working and took care of some legal aspects. You are now able to register yourself as a prospect customer by clicking on the login button and sending an email. We solved several infrastructural problems including deploying our app to the Amazon cloud (EC2).
If you would have asked us this morning, if we would be able to accomplish this - nobody of us would have said "yes" probably :-) It was a great day and we learned a great deal of things about all the new frameworks and technology we never used before!

Sven working hard to keep the backlog up-to-date. We are working to fast :-)

We are very proud of our layout. Especially because there are no designers in our team. If you like our design, too - or hate it: Please tell us! We need feedback! Fastly! (You may use the comments section, for example)

The current UI prototype contains some description on what we want to achieve. We love it :-)

Key learnings of Day 3

• Working with lower outside temperatures is MUUUCH better!!!
• JavaScript is shit
• JavaScript is cool
• We did not get any customer feedback today - which we regret. We will have to improve on that massively tomorrow!
• On the other side - we got a lot of things done, which was really great fun!
• IT guys cannot live without becoming sarcastic - even if successful ;-)
• We think the purpose of our project is not clear enough for visitors on the first view. We will have to improve massively on that!
• We are not able to acquire enough prospect customers by doing marketing over Facebook, Google+ and Twitter only. We will have to try out other marketing mechanisms.

Our main goal in the next two days is to come so far as to be able to go outside and sell our idea to passers-by. Functionality of the site should be so far, that those people will immediately see a value for themselves in using our project. Ambitious goal! Let's see...

The Limited Backlog - Addendum

In an earlier post I argued to limit the size of your product backlog. Some days ago, I met a co-worker who told me that some agile experts told him, that product backlogs always have to be limited in size. Superficially, this looks like the very same statement, I made in this former blog post. You might eventually be surprised to read, that I disagreed with the statement, my co-worker made.

Why? Because it is very important to understand why and when limiting the size of your backlog makes sense! The main argument for limiting the size is to avoid the maintenance costs of many backlog items. Especially, if there is a probability, that they will never be implemented at all or the items are deteriorating fastly (what a waste!).

Now comes the pitfall: If limiting the size of your backlog leads to emerging "backlogs" in other places (e.g. at your customer!) you might eventually even increase the overall costs of maintaining the items, if the maintenance costs at the other spots are even higher than they would be in your backlog. This is definitely not what you wanted to achieve in the first place, when you limited your own backlog.

So if you do indeed limit your backlog (which is still extremely valuable), watch out and have a careful look, if the discarded items do indeed vanish, or are only cultivated elsewhere.

The Backlog - Keep it Short!

A problem faced by many Scrum teams is an overcrowded Product Backlog. But the even bigger problem is that many of those teams do not even see, that this is a problem! Why is it not a good idea to have a very large pool of work to do? It might even look like a positive message in the first place.

The problem with overloaded backlogs are manyfold:

• A backlog must be maintained and communicated. The longer the backlog, the more work this is.
• A long backlog often contains items, that will never be implemented - bringing those to the backlog and maintaining them is a waste of time and resources.
• A long backlog has a frustrating and demotivating effect. Nobody wants to feel like Sisyphos all the time.
• A long backlog is nothing more than a long queue. You might read "Flow" by D. Reinertsen and let you convince, that long queues are one of the worst things that can happen to you in product development.
• ...

But what is the solution to this problem?

An obvious and easy solution would be to limit the work pooled in the Product Backlog (i.e. applying a WIP constraint on the Backlog). You can do this either by limiting the number of Stories in the Backlog or by limiting the number of Story Points. Two questions emerge immediately from this approach:

1. What will I do with the work, the customer wants me to do that does not fit into my product backlog?
2. What might be a reasonable upper limit for the amount of work in the Backlog (maximum queue size)?

My first answers would be:

1. If the customer has work to do that is more important than work currently in the backlog - let him replace some items. If the customer asks for less important features tell him to come back later. This approach adresses many of the problems with long backlogs and makes transparent to the customer that he is working with a bottleneck (your Backlog!). You can then work on problems causing this bottleneck.
2. Inspect and Adapt on this number! A good first shot would probably be to limit the backlog to the work that is possibly achievable in three month. This depends largely on your context and how stable requirements or User Stories are.

If this solution seems to be to mild for you and you need more radical solutions this article might be a valueable source for you :-)

Update 1: Some further remarks on this topic.