Dual-track Team Review and Retrospective

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.