Story Mapping

Story Maps are a different way to visualize your Product Backlog. This post will give you a brief intro so you can build your own.

What’s the Problem

We all know that the Product Backlog is the prioritised list of user stories we need to implement in up coming releases. So what are the problems that exist with a backlog that might cause us to look at another tool to use in conjunction with the backlog.

1. Backlogs are usually lists in Excel and make it difficult to visualise what needs to be done.
2. There is no way to show a connection between a larger feature and the 3 smaller stories that make up that feature in a backlog.
3. The order of workflow is not visible in stories in a backlog.
4. Usually release scoping happens at the larger feature level since it’s unwieldy to work at the lower story level when planning releases.
5. Backlog’s don’t offer any way to confirm if you’ve covered everything.

Breaking Down User Stories

I’m preparing to co-train my first Certified Scrum Product Owner (CSPO) course next week with Peter Hundermark. In preparing I found some old notes I had on a session on breaking down user stories. I though it would be good to share them.

It’s sometimes difficult to make stories small enough so that a team can deliver several of them in a two week sprint. Scrum works much better when we have smaller stories so here are some techniques to help you breakdown user stories.

The Importance of Vision

I have spent a lot of time working with ScrumMasters and teams doing root cause analysis of their problems, and very often one of the main root causes of a number of issues is a lack of a vision of where the product or team is going. Unfortunately vision is a much abused term in business today, and most attempts to create one involve glazed looks from people who have attended one to many corporate seminars that didn’t lead anywhere.

So I spent some time brainstorming with my team exactly why we think a vision is necessary. We came up with 3 reasons that we think teams need vision:

• To unify, because we gain momentum if we all pull in the same direction.
• To inspire, because we enjoy work more if we understand how we are contributing.
• To empower, because we make better decisions and take responsibility if we can visualise the outcome.

Release Planning with Scrum

As mentioned in a my Fixed Price Fixed Date Scrum post, there are some techniques you can use to help you build a release plan that you can communicate to customers. This release plan can also been used as the basis of a contract, if required. Below are 7 steps to help you do this.

Fixed Date Fixed Scope Scrum

Often when talking to people transitioning to agile or thinking about it I get asked the question: “Agile seems great, but in our business we need to engage in fixed scope fixed date projects with our customers, so how can Scrum work for us?”

Usually when I am asked this I realise that the person I am talking to believes that agile is an alternative to waterfall to deliver the same thing, and they are trying to choose between the 2 approaches, kind of like choosing between vanilla or chocolate ice cream.

However what you need to realise is that agile and waterfall are not in the same category, they are not even trying to achieve the same thing in my view. Only when this is understood will people stop asking how they can get waterfall artifacts from Scrum, and instead embrace what agile has to offer.