Dual-track Stakeholder Review

by | Articles

tl;dr:

Your product team will need to keep its work visible to stakeholders outside the team. If your product team is doing both discovery and delivery, you’ll need to review both those things. If you’re new to dual-tracking, use this recipe as a starting point.

Stakeholder Product Review Recipe

Purpose: Keep your product’s health, your discovery work, and your development work visible to the whole organization.

In Scrum, sometimes this is called a Sprint Demo. Some teams call this meeting a Showcase. You might know this as the thing your team needs to do every few weeks to keep your work visible to the whole organization.

There are lots of others in the organization who are likely interested in what you’re working on, and what you’ve accomplished. You’ll need to make this work visible to them. Unlike your team, these others probably don’t know the details of what you chose to build, nor where they fit into the big picture. So, you’ll need to plan on connecting what you accomplished and learned back to the product. This is also an excellent opportunity to learn from them, and to get their support.

Do use this review to show the outcome of your efforts. Stakeholders should care about that.

Don’t use this meeting as a place for stakeholders to criticize your team’s planning or the way your team works. That’s your team’s responsibility to manage.

Who: Invite everyone who’s interested.

This is a big public review. Anyone interested is welcome. Make sure your whole team is there. Seeing others’ reactions to what they’ve done, either positive or negative, helps remind them that what they’re doing matters.

Some organizations combine multiple product teams’ reviews into one larger stakeholder review. This cuts down on the number of meetings stakeholders need to attend routinely.

How long: plan for 30-90 minutes. This review should be faster, and at a higher level than your teams’ product reviews.

Bring food. I promise everyone will like what you have to say when they’re loaded up with carbohydrates. Even bad news goes down easier with sweets.

1.     Review your current product’s health

If your team is responsible for an existing product or product area, you’ll need to review how that product is doing. If you don’t currently have something in production that users are using, skip this part. Hopefully you’ll get something shipped soon.

When reviewing your product or product area’s health, make sure you connect what your focusing on to the metrics that matter for the organization.

Discuss your product’s Key Metrics, or KPIs:

  • What 2-4 metrics are you currently paying attention to about your product or product area and what are their values?
  • How do those metrics connect to those that impact the business such as revenue, cost savings, or retention?
  • How do they compare to what you expected? To the last cycle? To last month? To last year?
  • What should you celebrate? What should you be watching out for?

Discuss any subjective data on your product:

  • Quotes from customers about your current product that came from discovery work, customer surveys, or customer support

2.     Review discovery work

Reviewing discovery is critical. The best time to get feedback from stakeholders is before you’ve invested lots of time building something. If you’re showing real lessons learned from putting software in front of customers and users, they’ll value learning what their customers actually think. Often, the only thing that trumps an executive opinion is a cold, hard fact.

  • Discuss each opportunity you’ve taken up briefly: whom it’s for, why we’re building it, and the outcomes you expect if it’s successful. Make sure you tie that opportunity back to the value proposition for your organization.
  • Discuss your hypothesis at the beginning of the cycle and how it changed during the cycle:
    • What were you wrong about? And, what tests lead you to believe you were?
    • What were surprising new facts that changed your hypotheses?
    • What parts of your hypotheses were strengthened?
  • Discuss and show the work you’ve done to understand the problem and the solution. This may include things like proto-personas, story maps, or UI design.
  • Discuss and show prototypes and experiments you’ve run. Discuss what your customers and users are saying about your solution. If you have experiments that you deployed to a limited set of users, discuss any data you were able to get from measuring their use.

Notice that you’re not explicitly discussing the time budgeted for discovery or reflecting on your learning velocity. Your team owns the quality of its planning and its work. You’ll certainly answer questions and share how you did thing when asked. But, their no need to open yourselves up to micromanagement.

3.     Review delivery work

It’s been my experience that stakeholders are focused on what and when you’ll release to customers and users. They should be because it’s not until after you release a viable solution that you’ll be able to observe real outcomes and get real value. They’ll be interested in progress made toward that goal.

Review the delivery work you’ve completed at a solution-by-solution level. Think of the solution as the big rock that’s more relevant to stakeholders. The feature or capability that you’ll release. Some using story jargon may think of this as an epic.

For each solution:

  • Review the solution’s target customers, users, and outcomes. It’s good to remember why we’re building this and what success means.
  • Discuss and show the results of stories built for each solution. Stakeholders will offer feedback. Hopefully if they had a chance to give feedback when you were doing discovery work, the feedback at this point will be “Yup, that still looks good.”
  • Discuss the stories holistically. If you’re using a development strategy like the Mona Lisa strategy explained in User Story Mapping Chapter 4, you’ll need to explain to them why the software looks incomplete at this point. Remember that they may want to see a square inch of a complete portrait, and not the software equivalent of a sketch of the whole canvas.
  • Share with them your progress toward getting this solution releasable. How much work is left? What have you learned while building the solution that will affect its successful delivery?

Be prepared to write stories for new opportunities, or for changes you’ll need to make.

It’s possible that others in the room unfamiliar with what you’re building and why, will suggest things that aren’t a good idea. Respectfully and gently remind them of the target audience and outcome for the solution, and why what they’re suggesting might be a great idea, but doesn’t support the outcome you’re currently focused on.

Notice that you didn’t discuss your team’s development velocity and how that relates to what you’d planned on. Keeping your commitments is your team’s responsibility. Use your team’s review and planning meetings to discuss how you’ll meet those commitments.

Keep your work visible to everyone in your company. Help them be excited about what you’re doing and learning.

Dual-track Team Review and Retrospective

by | Articles

tl;dr:

If you’re using a typical Agile process like Scrum or XP you’ll work in short 1-3 week Sprints or Iterations. You’ll finish each Sprint by reviewing the work you’ve done, and reflecting on how you could change the way you work to improve. If you’re a product team doing both discovery and delivery, this review and retrospective will be different than a team doing delivery work only. Use this recipe as a starting point to learn how.

If you’re using Scrum, this is a Sprint Review and Retrospective. If you’re using XP terminology, this is an Iteration Review. If you’re like some teems I’ve worked with you might do this Friday afternoon before everyone leaves, or Monday morning before you plan the next weeks’ worth of work.

One of the core characteristics of an effective process is stopping and reflecting on the work you’ve done, and using what you’ve learned to make changes to how you’ll work going forward. Yes, it’s an Agile tenet. But, it’s just a characteristic of any effective way of working.

Team Product Review and Retrospective Recipe

Purpose: The team that worked together to understand their product development—and who made a short-term plan for doing discovery and development work—must stop and reflect on the quality of their work. Use a short workshop to accomplish this.

Who: the whole product team

Constrain this workshop to include only the people who worked together to understand and plan the work. Include the product owner and any others on the product team, as well as developers, QA, and anyone whom did active delivery work. Yes, I’m saying that it’s okay to exclude business stakeholders. We’ll share with them soon enough. But right now we need a safe place to talk.

How long: plan for 1-3 hours. It depends on the size of your team and the length of the time-box you’re reviewing.

Bring food. Years ago, in my team, this workshop simply couldn’t start if we didn’t have bagels.

1.     Evaluate your current product’s health

If your team is responsible for an existing product or product area, you’ll need to review how that product is doing. If you don’t currently have something in production that users are using, skip this part. Hopefully you’ll get something shipped soon.

Discuss your product’s Key Metrics, or KPIs:

  • What 2-4 metrics are you currently paying attention to about your product or product area?
  • What are their current values?
  • How do they compare to what you expected? To the last cycle? To last month? To last year?

Discuss any subjective data on your product:

  • Quotes from customers that came from discovery work, customer surveys, or customer support

2.     Evaluate discovery work

Reviewing discovery is critical. Show what you’ve learned from your customers and users.

  • Discuss each opportunity you’ve taken up briefly: whom it’s for, why we’re building it, and the outcomes you expect if it’s successful.
  • Discuss how your hypotheses changed during this cycle:
    • What parts of your hypotheses were wrong?
    • What new facts did you learn that changed your hypotheses?
    • What parts of your hypotheses were strengthened as a result of your discovery work?
  • Discuss and show the work you’ve done to understand the problem and the solution. This may include things like proto-personas, story maps, or UI design.
  • Discuss and show prototypes and experiments you’ve run. Discuss what your customers and users are saying about your solution. If you have experiments that you deployed to a limited set of users, discuss any data you were able to get from measuring their use.
  • Discuss your learning velocity: the amount you’ve learned relative to the amount of effort you put into discovery.

3.     Evaluate development work

Start by discussing and showing the software built as a result of the stories. Make sure you bring it up on a screen, and get a chance to try it out. All of it. In big teams, it may be the only chance everyone has to see one another’s work.

Grade your quality subjectively as a team. Grading will drive out lots of good discussion.

  • Discuss the quality of user experience. Not just how the UI looks, but how it feels to use. Is it as good as you expected? Grade yourselves on a scale of 1-5, with 5 being best.
  • Discuss the functional quality. Did testing go smoothly, or were there lots of bugs? Do testers expect to find more bugs as more software is added, or as they get more time to test? Grade yourselves on a scale of 1-5, with 5 being best.
  • Discuss the code quality. Did you just write code that will be easy to maintain and grow? Or, did you add to the technical debt you’ll need to clean up later? Grade yourselves on a scale of 1-5, with 5 being best.

Write stories to correct quality issues you see in the product.

4.     Evaluate your original plan

If you were working in a time-boxed iteration or a sprint, you started by making a plan and a prediction for how much you could get done, both discovery and development. Was your plan a good one?

  • Decide which stories are and aren’t done. This may be harder than you think. Having this discussion helps your team build a common definition of what they consider to be done. Does “done” mean there are automated tests? Does it mean that all manual testing is done? Does it mean that product owners or UI designers have reviewed it?
  • Total the number of stories you agree are done. You can total the stories, or the original estimates of your stories. This is your development velocity.
  • Total the stories started and not completed. If it’s a lot, it’ll signal you need to work on your planning. I call this amount the overhang. Someone I used to work with called it hangover, because it makes your head ache.
  • Discuss the amount of time budgeted on discovery work. Since discovery work was time-boxed, you need only evaluate whether you used the time you planned. Ask yourselves if you used more time than you budgeted? Using too little will hurt you later when you don’t have things ready to build that you feel confident in. Using too much may hurt your chances for delivering what you’ve committed on time.

5.     Review and improve your process

  • Discuss the way you worked over the last development cycle. Could you make changes to the way you work to:
  • Improve the quality of what you learn doing discovery?
  • Improve the whole-team participation in discovery?
  • Improve development quality?
  • Improve your ability to predictably plan?
  • To make it more fun to be at work every day? Because if you’re having fun, I promise you’ll be able to go faster.
  • Review any changes you made last development cycle. For each change should you:
  • Keep the change in place?
  • Take the change out?
  • Adjust it and try it again?
  • Together agree on the specific changes you’d like to make during the next cycle. It’s best to make just a few changes. One to three is good.

This process improvement discussion is commonly called a retrospective, and there are lots of great approaches to performing one.

If you’d like to look at some more comprehensive recipes for retrospectives, try the book: Agile Retrospectives by Esther Derby and Diana Larsen.

Dual-track Daily Standup

by | Articles

tl;dr:

If you’re a team working together on a product you’ll need a quick review and planning meeting every day. If you’re a team doing both discovery and delivery, that daily review and planning may go a bit differently. Use this recipe as a starting point if you’re new to dual-tracking.

Purpose: Use a daily standup meeting or team huddle to review your progress on the previous day and plan your work today.

Dual-track daily standup recipe

If you’re already practicing an agile process, you’re probably familiar with a daily standup meeting. And, it’s been my experience that for some teams this can be one of the most annoying parts of the day. If it is, this may be a hint you should change the way you’re doing things.

Remember: This isn’t a status meeting.

This is the team’s time to figure out how they can work together to make as much progress as possible today.

Who: the whole product team

How long: Keep these meetings 15 minutes or less. If a problem takes more than a minute to discuss or solve, use this meeting to plan a time to discuss it afterward.

1.     Discuss any team news or general announcements everyone needs to know

The standup meeting may be the one time in the day that the whole team is together.

2.     Discuss development work

Review each story in progress. Hopefully there are only 2 or 3. If you have more stories in progress, it may be a symptom of not working together, or “swarming” to get stories completed faster.

For each story in progress discuss:

  • What progress was made the previous work day
  • What challenges might be slowing things down or blocking progress
  • What can do together today to move things forward

While discussing development work it’s helpful to look at simple visualizations:

  • A task board showing the work to do, in progress and done
  • Mock ups or visualizations of the software you’re building – this makes it easy to explain exactly what you’re working on

Notice we’re discussing our progress story-by-story and not person-by-person. Remember it’s not about who’s most busy. We’re all busy. It’s about the progress we’re making on the software we agreed to build. Keep the focus there.

This team at Atlassian holds their standup in front of a flow for the feature they’re working on.

3.     Discuss work to prepare for next cycle

Part of the team’s work is refining development stories for the next cycle. If there are stories that need refinement workshops today, let people know during the standup so that can attend if they want.

4.     Discuss discovery work

We’ve saved discovery discussion for last. It’s OK for team members who aren’t involved in discovery work to leave and get to work on development work.

Review each opportunity in progress:

  • What are next tests, customer interviews, or work you’ll be doing to refine and advance your hypotheses.
  • How can other team members participate?

As with discussing development work, it’s useful to have visualizations to support the discussion:

  • Use a discovery task board that shows your current hypotheses, next most important question, and discovery tasks
  • Keep an evidence board that shows personas, journey and story maps, user experience sketches, and any other information that supports your current hypothesis
An evidence board at Carmax

More reading: Jason Yip, currently a coach at Spotify, has a useful paper describe lots patterns and approaches to standup meetings. While he doesn’t explicitly discuss discovery work, you’re sure to find some useful advice in it: It’s Not Just Standing Up: https://martinfowler.com/articles/itsNotJustStandingUp.html

Dual-track Sprint/Iteration Planning Recipe

by | Articles

tl;dr:

If you’re using a typical agile process like Scrum, you’ll break your work into Sprints or Iterations that usually range from 1-3 weeks. You’ll start each Sprint with a planning meeting. If your team is a product team engaged in both discovery and delivery, your planning session will need to account for both kinds of work. This recipe will give you a starting point.

Sprint/iteration planning recipe

Purpose: use a team planning session to set goals and plan work together as a team. The team owns its plan. It isn’t given to them.

Prepare

Who: the core product team including the product owner/product manager and the few people the lead discovery and development for your team’s product.

How long: this is a continuous activity. You may spend a little bit of time every day or every couple days. Just be ready for the team planning meeting or it makes it challenging for everyone.

1.     Choose delivery stories a cycle or two ahead

If you’re a product owner, meet routinely with your core product team to discuss the progress of the solutions underway. Choose the stories that you’d like to take on next to move those solutions closer to release.

2.     Workshop/refine stories ahead of time

For those on the product team, make time to work together with team members ahead of the planning session. Dig into details, split larger stories, and consider multiple options. In my book User Story Mapping, look back to Mat Cropper’s story in Chapter 7. When I spoke with Mat, one of the things he most looked forward to was the series of short, half-hour ad-hoc story workshops he had us developers and testers get ready for planning.

3.     Review discovery opportunities a day or so before planning

Since you learn something after every cycle of discovery validation, it’s hard to choose these too far ahead of time. It may be as simple as carrying forward the opportunities you’re working on the in the current development cycle.

Be ready to talk about the opportunities you’ll be exploring over the next sprint. Be ready to talk about your learning goals. And, be ready to discuss the amount of whole-team participation you’ll need. You’ll need to give the team an idea of how much help you’ll need for them in the coming cycle.

4.     Invite the whole team

And any others whose help you might need during the upcoming development cycle. Hopefully your planning session is already on the calendar. It should be a routine workshop that follows the cycle-end review.

Plan

Who: the whole product team responsible for doing the work. Optionally anyone else that may work with the product team during the next cycle.

How long: plan for 1-3 hours. It depends on the size of your team and the length of the time-box you’re planning for.

1.     Start by discussing the big goals

You’ve chosen some opportunities to move forward with discovery work and some stories to work on delivering. How do these opportunities and delivery stories help advance your product?

2.     Review the discovery opportunities you’ll be engaged in and agree on the amount of team time needed

Review each opportunity – there should only be one or two. What are they? What’s the benefit for building them? What are the risks or assumptions you’ll be working to test? How might the team help in this effort. Agree on a time-box for team involvement. You’ll need to know how much team time you’ll be using for discovery to figure out how much development work you’ll be able to take on.

3.     Review the stories you’ll be turning into deliverable software

Don’t go into extreme detail here – just enough to give everyone the big picture. Use lots of pictures. Bring in decisions that smaller groups made in story workshops.

4.     Set a time-box for the delivery team to plan on their own

Remember, crowds don’t collaborate. And the people building and testing this software need to do some real thinking to create their recipes for building these stories. Give the team an hour or so to break into small groups and work together on the stories. If you’re a product owner, UI designer, or business analyst, stay close by. Observe if you like. But be ready to answer questions that’ll help them move fast.

5.     In small groups, create a plan for each story

Work in small groups that include developers, testers, and anyone else that has work to do to turn the story into working software.

  • Discuss your approach to building each bit of software. Write out development tasks that describe your plan. But remember that you likely can’t anticipate everything. Be open to identifying new tasks as the development cycle progresses.
  • Discuss how long each bit of software is likely to take.
  • As a development team, decide how many of these stories can be successfully completed in the delivery cycle. Don’t forget to consider holidays and days off.

6.     Together, agree on the plan

At the end of the time-box, and after the team does their plan for each story, they’ll need to come back and share their plan. Not every detail, because that would be super-boring, even to them. But, what’s important is for the team to be clear about what they believe they can get done in the cycle. They should take this plan and their agreement seriously, especially if they want others to consider them reliable and predictable.

Agreeing may take a little time, especially if all the work that needs to be done won’t fit in the development time-box. It’s lucky you know some tricks for slicing stories down thinner. Try dialing back a story from better to just good enough. That should make it fit.

7.     Celebrate

You’re done. In the past, we liked planning in the afternoon. We tried to finish a bit before quitting time. Then we’d celebrate by taking the rest of the day off. We showed up the next day refreshed and ready to start working on the plan we created together.

Dual Track Development is not Duel Track

by | Articles

tl;dr:

If you’ve heard the term “dual-track development” before, this article explains where it comes from, and what it means. Here are the key points:

  • Development work focuses on predictability and quality
  • Discovery work focuses on fast learning and validation
  • Discovery and development are visualized in two tracks because it’s two kinds of work, and two kinds of thinking
  • Discovery is a necessary part of product development. Practice it with the same agile and lean principles in mind.
  • If we’re doing discovery right, we substantially change and kill lots of ideas.
  • While a product manager, designer, and senior engineer may lead and orchestrate discovery, they must involve the whole team in discovery tasks wherever possible. Keep discovery work and progress visible to the whole team.
  • Keep measuring and learning even after you ship.

Now, if anyone asks you what the article is about, you can answer them without reading the next 1,500 words.

No one really named it dual-track

Years ago, I was teaching a class with my friend Marty Cagan. It was really just my stuff and his stuff mashed together in a 3-day class. But, during my part I put up a model that I normally show when talking about how Agile thinking and product thinking work together in the same process. The model looked a little like this:

I’d hand-drawn my own version of the model, so it did’t look exactly like this. But, Marty asked me where this model came from. I opened the original paper from Desiree Sy (pronounced See) called Adapting Usability Investigations for Agile User-centered Design.

This is Desiree. You’d like her. She’s very smart.

Her 2007 article describes a common pattern which lots of people doing rigorous design and validation work in Agile development had already arrived at. Because, it’s really the only way this stuff can work. At the time, Desiree was working with Alias, now an Autodesk company, and she and her colleagues there had this working pretty smoothly. They were doing what most people at the time considered somewhere between super-hard and impossible. But, for them it seemed natural. Not easy, but it worked.

Marty asked me “what’s this model called?”

“It doesn’t really have a name” I said. “It’s just the way it’s done.”

“What does she call it?” Marty asked.

We scanned the paper and found this paragraph:

If I extract the important bit, it says

“… we work with developers very closely through design and development. Although the dual tracks depicted seem separate, in reality, designers need to communicate every day with developers.”

And that was it. Marty began using this term in his teaching to product managers. And since I often teach to the same people I began using that term. And gradually others began using that term.

Now I need to tell you I hate the term, and here’s why.

It’s Dual Track, not Duel Track

People just don’t read. It’s a miracle you’ve read this far yourself. Congratulations.

But people do look at pictures. And that picture of dual track seems to suggest different jobs for different people – like product managers and designers figuring out what to build, and developers building it. And in the worst of cases, you may interpret it as developers needing to wait weeks for product managers and designers to get their sh*t done.  It’s not supposed to be that way. If the whole team is responsible for product success, not just getting things built, then the whole team understands and contributes to both kinds of work.

I’d love a different term, and a different picture. But, I don’t have a better term or picture right now. Although I’ll try to draw a few more pictures to supplement this one.

There are two kinds of work, and there’s no way around it

Development work

If you’ve worked in Agile development before, you know teams will talk a lot about velocity. But the velocity they’re talking about is development velocity. Teams hand-wring about their predictability. At the beginning of a sprint, they’ll estimate velocity, and at the end they’ll measure it. Ideally their prediction was accurate.

When you’re delivering production quality stuff, quality is super important. If we’re putting software into production, quality, scalability, performance, localization, and lots of other concerns are important. So, finished development work should be built, tested, and reviewed by others to look after all these concerns. Agile teams will talk a lot about “potentially shippable software” which really means that they may not have built enough of it to ship yet, but once they do, the quality is high enough that they could ship it confidently.

Development work focuses on predictability and quality

Discovery work

One of the tragedies in software development, and all product development for that matter, is that much of what we build doesn’t succeed. It doesn’t deliver the benefit we’d hoped. So, that’s a problem. But, even before that, it takes a bit of time to learn enough about the problems we’re solving to make good decisions about what we should build. We use discovery work to do all that. To answer questions, to test ideas, and to avoid – as much as possible – wasting time over-investing in quality stuff we shouldn’t have built in the first place.

We want to learn as quickly, cheaply, and safely as we can. So velocity is important during discovery too – but this is learning velocity.

Discovery work focuses on fast learning and validation

Because the goal is learning, not working software, a discovery learning loop looks a bit like this:

It starts by describing:

  • What we believe is the problem we’re solving and for whom
  • The solution we’d build to solve it
  • How we’d measure success

That’s our bet, our best guess, our belief, our hypothesis. All of those are uncomfortable words for people who believe they’re building the right thing. But, the truth is, we’re always making a bet that we’ll get value. Embedded in that bet are lots of assumptions, risks, and maybe some questions. To focus our learning, we’ll choose the assumption, risk, or question that scares us the most and identify an experiment or method to learn. Then do it. Then use what we’ve learned to change all those going-in beliefs about problems and solutions.

Sadly, one of the most time consuming and expensive ways to learn is to build potentially shippable software. So we don’t – unless we really can’t come up with any other way to learn, or we’re really confident our bet is good. Remember, we’re not betting we can build it on time. We’re betting that people have the problem we’re solving and will happily try, use, and adopt our solution.

The most expensive way to test your idea is to build production quality software

That’s how a learning loop works. And there’s a few things you should know about it.

We do all this as fast as we can. In hours when possible. Sometimes it may take days. But, we hope it doesn’t take weeks. So, lots of discovery learning loops should fit in a typical 2-week sprint.

Discovery work often results in killing ideas. At the end of every test you’ve got a decision to make: build it, kill it, or keep learning. Yes, what I’m really saying here is discovery work can and should result in killing ideas. Not everything goes forward. This can make some folks really uncomfortable.

We time-box discovery cycles. To keep discovery costs from running away from us, we’ll timebox a test or experiment from a few hours to a few days.

We can’t predict what we’ll need to learn next – not easily. When we learn something really valuable, it tends to really change our going-in beliefs, and really change what our next biggest assumption or question is. This can really suck.

Discovery loops chain together a little like this:

By now it should be clear that both development and discovery work are critical. But the mindset you approach the work with, and your process for doing it, are very different.

OK, it’s really 3 kinds of work…

To actually start building work software, you’ll need to make a lot of tactical design decisions. These may not be the risky decisions that need validation, but they still need to be made. It’s often designers that need to spend time ahead of development to refine and finish design work in preparation for writing code.

If you’ve validated the product is worth building, you’ll likely need to finish some detailed design work before you write code

It’s happening all at once

It would be super-cool if we could all focus on discovery work, get it done, then move our focus to tactical design and development. And that could work if all team members had the same skills. But since some are good at writing code, some are good at user experience design, and others are good at a variety of other things, we’ve got an opportunity to be doing many kinds of work at once. So we do.

Discovery work happens concurrently and continuously with development work.

I draw the conjoined model a little like this these days.

Discovery work uses irregular cycle lengths. It’s “Lean” in that we’re trying to make the discovery cycle as short as possible. Ideas in discovery mutate and very often get abandoned. The best move forward into more deliberate development cycles. I’m not sure how to show all that stuff in a single drawing. But, I’m trying to in the one above.

Discovery and development are shown in two tracks because they’re two kinds of work, and two kinds of thinking

Two tracks, not two teams

But, you shouldn’t think of it as two processes – just two parts of one process. And, I think you’re doing developers and others on the team a disservice not to involve them in discovery work.

There’s usually more than enough discovery work to do and lots of ways to involve the whole team in doing it. If you feel pressure to shorten discovery work to “feed the beast,” it usually means you’re making decisions to build software before learning enough to be confident that you should. In the best case the outcomes are uncertain and usually the outcomes are just bad.

The whole team is responsible for product outcomes, not just on-time delivery

Busting dual-track myths

Let me hit the biggest misconceptions people have with the model again.

Myth: Discovery is a process that precedes agile development. It shouldn’t.

Discovery is a necessary part of product development. Practice it with the same agile and lean principles in mind.

Myth: All work moves from discovery to development. It doesn’t.

If we’re doing discovery right, we substantially change and kill lots of ideas.

Myth: The discovery team is different than the development team. It shouldn’t be.

While a product manager, designer, and senior engineer may lead and orchestrate discovery, they must Involve the whole team in discovery tasks wherever possible. Keep discovery work and progress visible to the whole team.

Myth: Once you move from discovery to development, discovery work done. It’s not.

This misconception is something that really bugs my friend Jeff Gothelf. He sees the production-quality software we build as our last-best experiment.

Keep measuring and learning even after you ship.

From Jeff Gothelf’s perspective, it’s all discovery and we learn from everything we make; be it a paper prototype, or the next feature in your production software. I agree with him.

There’s lots more to this story

I’ve talked conceptually about what discovery and development work is, and why you combine them in the same process. But, I’ve said very little about how you do this in practice. You should be feeling a little unsatisfied. Sorry about that.

But, this is the first article in a series I’m writing. Next articles will cover:

  • How to keep discovery visible in a typical Agile process like Scrum
  • How to adjust typical Agile planning, standup, and review meetings so they focus on both discovery and development
  • How to think through your next best experiment and scale discovery investment along with confidence

What questions are you left with? What’s your biggest challenge doing any of this stuff? Please let me know what I should be talking about that I haven’t mentioned above.

OK, here’s a little more…

It’s Nov 1, 2019 and I’ve added a few more articles that’ll give you some dual-track tactics. Specifically how Sprint/Iteration planning, daily standups, and reviews should go in a dual-track world. Take a look at these recipes:

Shameless plug

I teach classes in Scrum Product Ownership. But, they’re really classes about product management and design in an Agile context. Because, do you really need yet another class on Scrum? I’ve got upcoming classes scheduled with my friend Jeff Gothelf, author of Lean UX and Sense & Respond. The two of us tackle product thinking, discovery work, and this sticky dual-track stuff head-on. You should consider coming. Or tell someone in your organization that needs to understand this stuff about the workshop.

More Like This

Backlog Grooming Bugs Me

by | Articles

I wrote this article, a rant really, in April 2014. It was lost in a website shuffle a couple years ago, and someone recently asked if I could put it back. So here it is. But, it’s been slightly renovated from the original version to bring it up to 2017 code.

tl;dr:

Backlog grooming meetings are often the most unproductive and painful meetings in Scrum. If yours are great, then skip this article. It isn’t for you.

Here are the key points:

  • The most successful organizations have balanced product teams that meet routinely, usually weekly, to review and reorganize the backlog, and plan the work they need to do to get ready for the next sprint.
  • The best product owners have routine story discussions with team members to talk through options and details for the work they’re doing. 
  • Hold routine story workshops more frequently, at least once or twice a week.
  • Let participants “opt in” because you won’t have productive discussions with people who don’t want to be there.
  • Keep the discussions small. Smaller discussions are more productive. But always make sure you include someone who understands the functionality, someone who can write the code, and someone who can test it. 
  • Move conversations out of the tool and back to the whiteboard.
  • Bring in whatever you need into the conversation to help you tell the story. But plan on changing and refining what you bring in.
  • Acceptance criteria comes after building shared understanding of what we’ll build and answers the question “what would we check to confirm it’s done?”
  • Photograph the results of your collaboration. Put those photos along with notes in the tool later. Don’t confuse collaborating with documenting.

Most of what I said, and a lot more can be found in User Story Mapping. You should buy a copy. If you already have one, they make great gifts.

Stories and backlog grooming

Adopting new process language bothers me.  I was introduced to the Extreme Programming term “story” in 2000 and it wasn’t until 2005 that I stopped rolling my eyes when I heard the term and could actually begin to use it in sentences myself.

“Backlog grooming” isn’t a new term in the Scrum community, but it’s a term that still drives me up the wall.  Let me explain why.

The backlog grooming meeting as team torture

Years ago, I sat in on a painful meeting with a software development team I was just beginning to coach.  It was important that I learn the way they were working today, and respect the process choices they’d made so far.  It was my goal to observe and understand.  

In this meeting, the whole team gathered in a conference room and projected a screen from a popular Agile management tool onto the wall.  The screen showed the backlog.  One by one the team went through backlog items, opened each item’s document containing a user story, and then read through the details with the Scrum Master facilitating and driving the keyboard.  Team members asked questions about the story.  The product owner did his best to answer questions.  Guided by the Scrum Master, the team tried to write acceptance criteria for each story in the document using a Behavior Driven Development style “given-when-then” format.  

It sounds pretty straightforward.  At worst it sounds a bit boring. But it was worse, much worse.

It was clear by all the restless shifting in chairs and smartphone fiddling that no one wanted to be there.  The team didn’t seem to understand the product and  struggled to ask useful questions.  There were a couple developers that seemed to have an easy job participating and they seemed to delight in asking difficult questions the product owner couldn’t answer, or explaining to the product owner how the product “couldn’t do that.”  The more junior people seemed bewildered.  When they tried to ask questions they were often answered with eye-rolling and patronizing answers that made it clear to them that if they only knew the product or the domain, they’d have never asked in the first place.  The ScrumMaster tried to keep the team focused, but she had most of her attention on the tool trying to find stories and trying to get acceptance criteria keyed in.  She spent a fair bit of time correcting team member’s attempts at forming good acceptance criteria.

I sat at the back of the room watching, feeling the pain of the people in the room as the meeting dragged on for over two hours.  Toward the end, it was clear that people just wanted to escape.  When asked if they understood the story, or if the acceptance criteria made sense, they were quick to nod.  Their “yes’s” felt more like confessions extracted during torture than genuine agreement.   

At the end when people filed out of the room I heard grumbling comments like, “How can we get any work done if we spend all our time in meetings?”  

I asked someone, “How often do you do this?”  

“Every week” he winced.  

“What’s this meeting called?” I asked.

“It’s the backlog grooming meeting.  We have to do it in Scrum.”

It’s from this and many similar experiences with backlog grooming that I’ve come to develop a healthy disdain for both the term and the meeting it now refers to.

What I think Scrum creators really meant

I originally attended a Scrum class taught by Ken Schwaber in 2005.  When I dig back in my cobwebbed memory, I recall Ken saying that the Product Owner needs to keep the backlog groomed.  He explained that the backlog can turn into a mess of items expressed differently, overlapping each other, some no longer needed, and no longer sorted in priority order.  “Every sprint you’ll need to spend time keeping the backlog cleaned up,” is what I recall Ken saying.  Back then, he referred to this cleaning up as “grooming.” This made sense to me.

On the other hand, the meeting I keep seeing that’s called a “backlog grooming” doesn’t make sense.  In fact, any Product Owner who participates routinely in this meeting knows the one thing they can’t do in the backlog grooming meeting is tidy up the backlog.  It had better be pretty well groomed before the grooming meeting or things will go badly.    

As I read the current Scrum Guide,  I notice it doesn’t agree with what I recall hearing from Ken many years ago.  Possibly I’m imagining I heard it.  Today’s “Definitive Guide to Scrum” by Ken Schwaber and Jeff Sutherland does describe grooming as the process of, “Adding detail, estimates, and order to backlog items.” While doing that work makes sense, “grooming” may not be the word I’d choose.   The meeting I commonly see seems the poorest possible process solution for doing the work we need to do to get stories ready for upcoming sprints.

“Grooming” has been deprecated – call it refinement

The first time I said “grooming” in a class I was teaching in the UK I got a several snickers from people in the room. Do a quick google search on the term “grooming” and you’ll see the kinds of things the term commonly refers to.  One common meaning is pretty disturbing, and it’s not “dog grooming.” For that reason most of the Scrum now tries to use the term “backlog refinement” – but sometimes they still slip.

What went wrong

In trying to better understand the work successful product owners do to fill their role, I’ve spent a lot of time interviewing them.  I always ask product owners to “tell me about your worst day on the job.”  At least half the time I hear them describe an awful experience during a sprint planning meeting – that meeting where the whole team gets together to plan their work for the upcoming development cycle.  They describe the team asking them questions they weren’t prepared to answer.  They describe the team complaining that they didn’t have enough information to estimate work, to determine if they could or couldn’t get it done in the next couple weeks.  They describe the team and the company leadership blaming them for not doing enough work to prepare for the upcoming sprint.  Through hearing these stories, I feel a lot of their pain.

When I asked successful Product Owners what they did to feel ready for the upcoming sprint, almost all of them described lots of frequent conversation and collaboration with team members to talk through upcoming work before the Sprint.  Many of them described learning the hard way that on their own they could never come up with the right information to support a story.  They needed the discussion with team members to help them work through the details and to understand what options were feasible and what details were necessary to help team members proceed.

So, here’s where I believe the Scrum community went a little sideways.  This is the pretzel logic I think happened somewhere along the line:

  • Sprint planning is painful when we’re not prepared
  • Collaboration with team members before the sprint helps prepare
  • Product Owners are supposed to keep the backlog groomed
  • The whole team is responsible for the work done in the Sprint
  • [Big idea] Let’s create a new whole team meeting called the “backlog grooming meeting” where the team and product owner collaborate to get ready for the upcoming sprint!

I’m hoping you have trouble with that logic, because I sure do.

What really works

The Product Owner does need to keep the backlog in good order and deliberately budget time every week to look over the backlog pull out things we no longer need, reorganize and rewrite items, and prioritize work so that we know what’s coming up at least in the next sprint and often, a couple sprints out.  

I advocate widening product ownership to a team.  In working with my friend, Marty Cagan, we refer to this team as the “discovery team” or the “core product team.”  It’s their job to discovery what should be built.  A balanced discovery team includes someone who understand the business concerns that motivate building software, users and their concerns and how they’ll use the software, and someone who understands the engineering concerns and can help identify what’s feasible to build.  It’s from this intersection of valuable, usable, and feasible that good products spring forth.  A single Product Owner may lead the team, but it’s still a team.

The most successful organizations have balanced product teams that meet routinely, usually weekly, to review and reorganize the backlog, and plan the work they need to do to get ready for the next sprint.

Product Owners need frequent collaboration with team members to help everyone think through and understand what we can build.

I remember the good old days in software development that when we were faced with a challenge, we rushed to a whiteboard to talk things through.  A few of us would have often loud discussions, drew lots of pictures, argued a bit, shared ideas, and eventually we’d agree on what we could do.  Often we’d end up realizing we might need to prototype something or talk to users to learn something we didn’t understand.  This worked well and it still does.

The best product owners have routine story discussions with team members to talk through options and details for the work they’re doing.  

Good Product Owners keep these discussions small and include the people passionate about the work and helpful in thinking through the details.  They know we’re here to learn, to consider options, and make decisions.   They know that we’re not meeting to communicate requirements, but that together we’ll make decisions about what to build that best solves problems.  Ultimately, participants drive to some agreement on exactly what we’ll build.  They’ll answer the question, “What would we check to confirm it’s done?”  The answer to that question is acceptance criteria or story tests.    

Acceptance criteria comes after building shared understanding of what we’ll build and answers the question “what would we check to confirm it’s done?”

One of the better product Ownership groups I worked with holds Story Workshops at least once a week, sometimes twice.  They post on a visible calendar when the workshops will be and write in the names of the stories they’ll be workshopping in the next session.  The stories to be discussed in the next meeting look a little like “daily specials” at a restaurant.  Team members “opt-in.”  They decide if they want to attend or not.  If a workshop starts and they’re missing someone important, like a tester who’ll be responsible for verifying the work is done right, then the Scrum Master rushes out to see if they can round someone up to participate.  But, for the group I’m thinking of, most of the time the right people do opt-in.  Discussions are animated and fun.  Team members look forward to this opportunity to collaborate.  

Hold routine story workshops more frequently, at least once or twice a week.

Let participants “opt in” because you won’t have productive discussions with people who don’t want to be there.

Keep the discussions small. Smaller discussions are more productive. But always make sure you include someone who understands the functionality, someone who can write the code, and someone who can test it. 

One of groove-killers for backlog grooming meetings is projecting your backlog management tool on the wall and asking one person to type. So, stop it. Move your conversations back to what we know works, the whiteboard. Stand up. Draw pictures. Bring in pictures to post on the wall. Make sure they’re on paper so team members can scribble changes and notes on them – because if it’s going well, they will.

Move conversations out of the tool and back to the whiteboard.

Whatever you bring into a story discussion is legal. Yes this includes formal specs, UML, use cases, workflow models, wireframes, or pixel-perfect mockups. They’re legal because you’ll use story telling and back and forth conversation to make sure everyone understands. And, because you know that everything is open to change, you’l plan on making changes and refinements during the discussion. It’s a workshop, so plan on working. And, it’s called refinement because we plan on refining things.

Bring in whatever you need into the conversation to help you tell the story. But plan on changing and refining what you bring in.

When you’re done with your workshop, someone will need to get all this stuff into the tool. Make it easy by photographing what you’ve done and putting that photo in the tool. You may need to transcribe a few notes from your conversation too. But, make documenting someone’s chore after the fact. Don’t confuse effective collaboration with documenting. The documents should be evidence that you did collaborate. They don’t replace collaboration.

Photograph the results of your collaboration. Put those photos along with notes in the tool later. Don’t confuse collaborating with documenting.

Later, at Sprint Planning, team members are familiar with the stories.  They helped decide on them.  They helped author the acceptance criteria, and are quick to help explain details to other team members who didn’t help workshop the story.  And, when “that guy” – you know the one – that guy who delights in poking holes in everything pipes in, team members fight back.  I’ve heard team members ask, “Hey – where were you when we workshopped this over the last couple weeks?!  It would have been good to hear this then.  Right now you’re just slowing us down.”

Use product team planning and story workshops to prepare

The combination of product team planning and story workshopping works.  

Yes, keep the backlog groomed and in good order, but don’t make the whole team do it.  If you’re the product owner, do a bit of it on your own, and lots of it with your closest collaborators – a small balanced product team.  

Use product team planning meetings to discuss how the release is progressing and to choose stories for upcoming Sprints.  Use the time together to identify the work you’ll need to do to get stories ready for the upcoming Sprint.

Use routine workshops with team members to work through the story details.  Keep these workshops small and productive.  Don’t exclude those who want to be there. However, don’t make people attend who don’t have a desire to contribute.  

Pay attention to what happens during sprint planning, everyday during the sprint, and later at a sprint review.  You’ll get a feel for the kinds of things you need to be discussing during workshops to help things go smoother.

 

Most of what I said, and an lot more can be found in User Story Mapping. You should buy a copy. If you already have one, they make great gifts.