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.
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.
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
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.
Jeff Patton and Jeff Gothelf have teamed up to deliver an honest, irreverent, and extremely useful 2-Day Certified Scrum Product Ownership course. This is a course with a deliberate and unapologetic product-centric and Lean UX bias. If you’ve learned Agile and Scrum basics elsewhere and felt that product and user experience concerns were missing, we’ll fix tha
Put a brain on your Scrum process
Scrum, or common Agile practice, as it’s commonly taught, isn’t enough to create successful products. In the worst of cases Scrum can lead smart, well-intentioned people into doing stupid things all in the name of building more faster. While building software isn’t easy, the hardest part is making good decisions about exactly what to build.
This workshop puts a brain on your Scrum process. In it you’ll learn how to build up from an Agile and Scrum foundation by knitting Lean Startup, Lean UX, Design Thinking, and effective Product Thinking into more holistic product design and development process. The result is an approach to product development that let’s you and your team focus on creating products your users love.
What you’ll learn:
This course will spend a little time on Agile and Scrum essentials and moves quickly beyond. In this class you’ll learn:
How to structure a Holistic Product Development process that leverages Scrum for delivery and brings in the best of product, design, and lean thinking
How Product Owners, UX Designers, and Engineers collaborate to lead Cross-Functional Product teams
Effective Collaboration Skills that help build shared understanding
How to frame product improvement ideas using a simple Opportunity Canvas
Characterizing your users and their needs using Proto Personas
Exploring how users work now, and with your future solution using User Story Mapping
Collaborative ideation using the Design Studio practice
Identifying a Release Strategy built from small viable releases
Validating product solutions using MVP Tests
Reducing the risk of late delivery using a Development Strategy
How User Stories really work, and how to use Story-Driven Development throughout your process
Keeping discovery work visible in Scrum
Facilitating common Scrum Ceremonies that place equal focus on discovery and development
Balancing continuous discovery and development using Parallel Track Development
Who should attend? (All key members of your team, that’s who)
This workshop isn’t just for product owners. One of the biggest misconceptions in Scrum is that the product owner is the “single ringable neck” solely responsible for building the right product. In fact, it takes a whole team focusing on product success. This workshop is ideal for:
Product managers, product owners, or producers
User experience practitioners
Engineers and testers
Scrum masters, agile coaches, and project managers
Business leaders
And anyone else on your team motivated by creating products your customers love
You should bring your team. Otherwise you’re just going to have to try to explain all this stuff to them when you get back to the office.
It won’t be boring
This workshop is fast-paced and collaborative. We’ll teach with a mixture of hand-drawing, slides, videos, storytelling and humor. You’ll get your hands dirty getting a taste of the many practices we teach.
Yes, you’ll receive Scrum Certification, and lots of other stuff…
This is a Scrum Certified Product Ownership course, and you’ll receive certification from the Scrum Alliance after attending the course. You’ll also receive a workbook, quick reference guides, and access to electronic versions of all the resources used in class. And participants will receive a copy of Jeff Patton’s User Story Mapping, and Jeff Gothelf’s Lean UX.
About your workshop facilitators:
Jeff Patton, author of User Story Mapping
Jeff Patton helps companies adopt a way of working that’s focused on building great products, not just building stuff faster. Jeff blends a mixture of Agile thinking, Lean and Lean Startup Thinking, and UX Design and Design Thinking to end up with a holistic product-centric way of working. Jeff has worked in software development for over 20 years in a variety of roles include product manager, engineer, project manager, coach, and consultant.
Have questions about this workshop? Email Jeff: info@jpattonassociates.com
Jeff Gothelf, author of Lean UX and Sense & Respond.
Jeff is a designer, product strategist, team leader and author. He’s been teaching teams across the world to rave reviews. Jeff has been creating software products for over 17 years with companies like AOL, Fidelity, WebTrends & TheLadders and Neo Innovation.
