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.

Jeff Sutherland points out the the best way to go fast is to have a definition of done (or “done done”) that means the software is shippable (coded, tested, documented, etc.).

The second best accelerator is to get stories ready (or “ready ready”) before the sprint planning meeting. For me, “ready ready” means that people understand stories well enough for the team to have a productive Sprint Planning meeting. Not one that takes ages and ages and stops because people have to catch a train or pick up their kids at daycare.

The purpose of the diagram is to provide a conceptual model for how stories get to be in a “ready” state. People need to talk about them and maybe do a little leg work. Who is responsible for getting stories ready? The Team! (Not the Product Owner as some might say). So good teams spend ~10% or their time getting ready for the next Sprint and ~90% on the current Sprint. Please note the amount of time will vary by team and project – 10% is a conceptual number.

Of course, most teams fall into the trap of focussing so much energy on the current Sprint they fall into the vicious cycle of low quality planning meetings and disorganized Sprints.

What if it takes more than “a little work” to get a story ready or to spilt a story? No problem, just create a Technical Spike story so that the whole team can tackle this tough story together. The outcome or acceptance test of the spike is that the story is split and that all the upcoming stories are “ready”.

The next rows in the diagram show that some people on the team may spend more time getting stories ready than others. For example, architects, SME (Subject Matter Experts), etc.  User Experience designers are often focussed on the Sprint ahead while docs folks are mostly on the last Sprint. Again the numbers here are conceptual.

Here are some other good posts on getting stories Ready:

• The Definition of Ready
• Ready-ready: the Definition of Ready for User Stories going into sprint planning

Happy Scrum!

Product Camp Toronto was above all a great networking opportunity since there were lot’s of breaks between sessions for conversation. The day started with people sitting at tables chatting – and boy was there a buzz!

In this post I am going to give a quick pass at the four sessions I was at:

• Keynote on what is a product manager
• How to treat Customers like a Market and Markets like a Customer
• Open forum on Crowd Sourcing
• Market Research with Innovation Games

 What is a Product Manager?

The short answer is: someone who makes choices on product every day. John Stetic used the graphs below to show the breadth of skill required for product management and walked through some of the archetypal product managers and where they shine.

How to treat Customers like a Market and Markets like a Customer

Nick Van Weerdenburg had an engaging and insightful session. For me, the most engaging concept is to conceptualize a market as a person. Really ask yourself – what are they like? Personality? What do they think of you? Do they know your product? Good stuff. Read more below.

Open Forum on Crowd-Sourcing

I offered to facilitate this session (since I am getting pretty good at facilitation) and there was no one else around. As it turned out, we had a great mix of curiousity, skepticism and practical knowledge.

At the end there seemed to be consensus that:

Crowd Sourcing is a valuable activity that makes the Product Manager’s life easier, results in a better product and all this with minimal additional workload.

Below is a summary of the Crowd-Sourcing Flow:

Market Research with Innovation Games

Like crowd-sourcing, Innovation Games®are a powerful way of connecting with customers. The main difference is that Innovation Games® are focussed on real-time collaborative games as a means of engaging customers and stakeholders to reveal what really matters to them and to get breakthrough ideas.

I ran the session to give people an idea about using in-person and online games support envisioning, identifying hidden needs, and prioritization. We also briefly played Buy A Feature game online – and there were more than a few people hooked on it.

Slides are below:

Also, for reference, here is the handout summarizing the games:

Summary

I had a great day a Product Camp and would definitely recommend it.

Here are the slides and reference links for the session Gino Marckx and I are giving at Agile 2010 in August

Triangle Model

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.

Team Perspective

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)

• Video of Mike Cohn at Agile 2008 and Slides
• Agile Estimation and Planning (book)

Story Map – structure the work in a grid that reflects actual product usage (Jeff Patton)

• Jeff Patton’s blog
• Presentation

Software By Numbers – prioritize work by Net Present Value of Minimum Marketable Feature

• Software By Numbers (book)

Customer Perspective

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 Analysys - Structured Questionaire 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)

• For Speedboat® and Buy A Feature® + more - innovationgames.com and Book

Company Perspective

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.

Slides

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

1. Identify Stakeholders
2. Identify work (Stories)
3. Estimate work (units, T-Shirt sizes); identify risks
4. Organize & Prioritize <– Focus of our game is on organizing
5. Communicate
6. Execution & tracking (Release burndown/up)
7. Re-prioritize

(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:

1. The missing stakeholder game – who are my stakeholders and why are the missing? (prioritization)
2. “Malfunction at the stakeholder junction” – AKA the dysfunctional stakeholder game. “I want this.” “No, I want this.” (prioritization)
3. 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

It was fun. Really fun. I played the role of product champion and facilitator.

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:

1. Align with Company Strategy
2. Balance stakeholder demands
3. 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.

Design-dead core

Do you have  a design-dead core?  Here’s a quick checklist (see mindmap below):

1. The code is fragile: difficult to work with and things break unpredictably
2. Little or no automated test harness.
3. Few experts who really understand the technology.

Innovator’s Dilemma

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.

Watch the video

The whole video is great, but for the part explaining the Innovator’s dilemma check out:

• Start: 35:38
• Stop: 45:07