I was at a client recently and one VP was convinced that Agile was “untrue” and there was no way it could possibly work. The problem was that he had never heard of backlog grooming or getting stories ready. Once he saw the infographic below, the penny finally dropped and he understood how this crazy thing called Scrum can possibly work with user stories.Read More
Here are the slides and reference links for the session Gino Marckx and I are giving at Agile 2010 in August
Selecting and delivering the most important work is a critical success factor in Agile projects. But how do you know what is important? Unless you are psychic, some help would come in handy. Consider the diagram below to help make sense of the wide variety of strategies and tools.
We explain three different perspectives: Company, Customer, Team.
The product backlog needs to be structured so that it informs the team of the vision and the work. Whenever the company or the customer priorities are not clear, the team will need to rely on general information and it’s common sense.
Theme Scoring & Screening – Relative or numerical weighting based on criteria (Mike Cohn)
Story Map – structure the work in a grid that reflects actual product usage (Jeff Patton)
- Jeff Patton’s blog
Software By Numbers – prioritize work by Net Present Value of Minimum Marketable Feature
The product backlog prioritization is done from the customer’s perspective, from the perspective of whoever is paying for the product in the first place, whether this customer is internal or external to the company doesn’t really matter. What is most valuable to the customer will be on top. Techniques focussing of this view require strong product domain knowledge, and a good understanding of the impact of specific features on the business.
Kano Analysis – Structured Questionnaire to determine feature relevance: Mandatory, Linear, Exciter
- See materials of Mike Cohn from Team Perspective: Theme Scoring & Screening
Innovation Games® – 12 Games to better understand your product and what’s important (Luke Hohmann)
Companies need to find a balance in distributing the effort over multiple customers and/or products. But they also need to take the company and product strategies into account, deprioritizing features that might be very valuable for customers but aren’t in line with the company’s vision. As well, this takes into account stakeholders other than customers and sales – support, professional services, etc.
Company and Stakeholder Strategy
- Aligning and Balancing Your Backlog
- Blog: Why Prioritizing Your Product Backlog for ROI Doesn’t Work
Business Value Game – Simulation to illustrate how organizations can define their own business value model.
- Game instructions
Allocation Model – helpful to balance priorities with divergent or competing interests
- See example by Alisson Vale: Slides 40-49
Where to go from here?
The most common questions we have gotten after presenting these techniques are “How do I decide where to start?” and “How do these work together?”
These are complementary techniques and are used to solve related problems. Our recommendation is to start with the area that is the biggest challenge for your project. Maybe this means talking to stakeholders you normally don’t talk to. Maybe it means putting a Story Map up on the wall. It depends.
Subtitle: How we created and played a brand new game all in one day.
On Day 2 of DeepAgile, Michael McCollough and Don McGreal got us started on with a game design workshop. From there we used open space to invent and play the game with other attendees. This blog shares what we learned about product backlogs and game design.
Getting started: A room with a view
The first job in open space was to create 3 consecutive session in the open space (one for each of: objectives, design and play – see photo). I announced that each open space session was independent and that people could attend just one or all – we would do a re-start at the beginning of each one. Working and collaborating with others – what a great way to use Open Space.
I scoped out an amazing room at NERD with a round table, ceiling-height whiteboard and a spectacular view. Perfect for inspiring a team and encouraging collaboration.
Learning Objectives: Keep it simple
We started with a long list of learning objectives at the end of Mike & Don’s workshop (see photo on left). We knew this was way too long and had it winnowed down to the three within the next hour (see photo on right). By the end of the day we had stripped it down even further to just the first objective: there are multiple ways to represent a backlog. KISS strikes again.
The Problem: Product Backlog Management has challenges
The starting place was to help product owners to organize and prioritize their backlog. We spent discussed the topic for a while to get on the same page. We figured out there are a whole bunch of steps involved in building and maintaining a backlog (See diagram below):
- Identify Stakeholders
- Identify work (Stories)
- Estimate work (units, T-Shirt sizes); identify risks
- Organize & Prioritize <– Focus of our game is on organizing
- Execution & tracking (Release burndown/up)
(We had a great diagram on the whiteboard but can’t find it. So I redrew it from memory and added some flourishes.)
The simple act of preparing brainstorming objectives for the game led to a better understanding for all of us on the full life cycle of a product backlog. The big picture allowed us to focus in on one part: organizing and prioritizing. Even this was too big! We split approaches and concepts into ones that were more about organizing and ones more about prioritizing. At this point we had three game concepts:
- The missing stakeholder game – who are my stakeholders and why are the missing? (prioritization)
- “Malfunction at the stakeholder junction” – AKA the dysfunctional stakeholder game. “I want this.” “No, I want this.” (prioritization)
- The Backlog is in the eye of the beholder – all about organizing based different stakeholder perspectives. (organization)
We did a strawman vote and there was a clear consensus around moving forward with the last one – on organization of the backlog.
Working together on the game
We started with the Pomodoro Technique to stay focussed and on track (yes, I even drew tomatoes on the whiteboard). In the design session, we got into a state of flow and just kept going to meet our timebox.
We had to deliver a game since it was announced and on the open space board! As my thesis supervisor said – “Nothing concentrates the mind like a deadline.”
We did lot’s of brainstorming. Everyone was really good about coming up with ideas and letting go of ones that weren’t working out. One idea Greg Ott came up with was that of a garden (see photo on right). After a while this turned into the the farm metaphor we decided to use for the game. In retrospect, having a huge wall to keep ideas alive was invaluable.
Playing the Game
Playing the game was a lot of fun. You could feel the energy in the air (see photo) and the room was packed with designers, players, and observers. We got mostly very positive reviews.
You can find the game rules and feedback here: Backlog is in the Eye of the Beholder Game v0.7 This is our current version. It is also posted on TastyCupcakes game site. Feel free to use and make your own.
Thanks to everyone who designed, played and supported us. Special thanks to core co-inventors: Warren Elliott, Greg Ott, Mary Gorman, Dan Zaino, Judy Rivais.
(This is part of a series on DeepAgile 2010 Games Weekend).
This is a review of Luke Hohmann’s excellent blog series on Product Backlog Prioritization. As usual, I have captured what I believe to be the salient points in a visual note. The main points are to:
- Align with Company Strategy
- Balance stakeholder demands
- Drive Profit
Starting at the top left and going clockwise…
Company Strategy. Do you know what it is? Do you know the top 3 priorities. Do you know the product strategy? As product owners, we want to eliminate the work that does not align with these. We also want to focus on those that are most strongly aligned with strategy.
Software By Numbers is a great concept but is difficult to use in practice. Firstly, no one has then numbers and secondly business value models need to account for intangibles.
Driving PROFIT is one aspect of a healthy model. Several different approaches (customer pipeline, market research, etc) can be used to identify key business drivers. Hohmann argues that these are at the theme or epic level rather than an MMF (minimum marketable feature).
Finally, it is critical that product releases satisfy internal and external stakeholders. For me, this is perhaps the deepest insight in this blog. Product owners need to listen to and support a wide constituency for a product to reach its potential value to an organization. In my work as a coach, I sadly notice internal stakeholders such as architecture, support and services are frequently ignored. If you haven’t already used them, Innovation Games® are a great way to understand and make choices.
Part of my standard training for Product Owners is to help them understand how they relate to everyone else in an Agile/Scrum world. Hence the drawing below.
Project Community Diagram
The Product Owner is not part of the team since their role is to ask for more to keep productive tension in the system. I like the way Ron Jeffries narrates about the Product Owner Role without ever using the term. This is a good story. So is the follow-up one.
I like the XP notion of the customer team to reflect the group representing the customers interests. (If anyone can suggest a good link/definition, I’ll add it.)
Why is the ScrumMaster outside? Their primary role is to act outside of the system to help it function and grow. Why is the ScrumMaster cheering on top? Ooops. That’s a bug. If I had time to re-draw, I’d put them underneath holding up the whole system as a servant leader.
So what do you do, if you don’t like the way I have parsed the world? Please help me understand your perspective – draw a picture to show me the world through your eyes.
Ken Schwaber has a great presentation where he talks about the Innovator’s Dillemma and how companies build a (design) dead core.
A typical (success) story
- Management – we need to hit the date.
- Developers – OK, we’ll cut quality but won’t tell you.
- Success! We made the date. We’re heroes!
BUT, this is a horrible long term strategy because you get a design-dead core and can no longer ship product.
Do you have a design-dead core? Here’s a quick checklist (see mindmap below):
- The code is fragile: difficult to work with and things break unpredictably
- Little or no automated test harness.
- Few experts who really understand the technology.
The purported dilemma is that you need to choose between fast delivery and maintainability. So, if you want to get to market fast you need to take shortcuts that are going to hinder you in the long run.
This is also called the inventor’s dilemma.
Agile to the Rescue
Teams that follow Agile practices avoid this peril in two ways.
By managing features and scope, teams can find the most valuable software to deliver by a certain date.
Technical practices such as automated testing, continuous integration and refactoring keep a code base healthy and maintainable. They also helps teams go faster.
Release Burndown to illustrate the Innovator’s Dilemma
Consider the chart below. Companies start at burndown line A. If they use Agile, they will stay there. Most companies don’t. So, release by release, they accumulate technical debt and the code base decays. After a few years, they build a design-dead core.
As a coach, I like to show teams the chart below and vote on their code base. Many companies are at line C with some area’s that are D.
Help! I have a dead core!
OK, so you’ve got a dead core. Sad news. There are ways to recover. I’d suggest you start with Michael Feather’s book Working Effectively with Legacy Code.