Dual-track Stakeholder Review

by Jeff Patton | 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 Jeff Patton | 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 Jeff Patton | 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.

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

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 Jeff Patton | 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.