Agile Product Management with Scrum : Chapter 5 : Sprint Meetings
In which I summarize and discuss chapter 5 of Roman Pichler’s book on product management in Scrum, on the product owner collaborating in sprint meetings.
Summary of Chapter 5
So here’s the deal on what Scrum is.
You take a small team.
You free them to focus on just one product, you free them to focus enough to take a thought to completion, and you stop interrupting them.
You empower them to own their processes and work; you give them trust and resources.
They collaborate and work, face to face, together, breathing the same air, all thoroughly understanding and communicating with one another. They become a real actual team working as a real actual team.
They deliver value to the organization and are radically open to and responsive to feedback.
Scrum is about having the right meetings with the right people with the right preparation and outcomes. And not having those other kinds of meetings.
This chapter is about the meetings built into Scrum.
Sprint planning
The product backlog absolutely must be well-groomed going into the sprint planning meeting. The product owner is responsible for ensuring this is so.
The product owner should be available at sprint planning to clarify requirements and answer questions.
The product owner should help rally the team around a vision for the goal of the sprint, an elevator pitch of why the team is undertaking that sprint instead of not.
And then the product owner should get out of the way. The product owner does not plan the sprint.
Rather, only the team can, given the quality inputs of a well-groomed product backlog and having rallied around a goal for the sprint, identify just what and how much the team wishes to commit to delivering in that sprint. Only the team can commit itself to a sprint backlog.
The team plans the sprint with the guidance of the ScrumMaster. The product owner supports this planning with a well-groomed backlog and with a rallying vision of what the team is trying to accomplish, why the backlog prioritizes what it does and the bigger picture of what those priorities mean.
Definition of done
- Have one
- Authored by and with buy-in from the team
- Write it down
- Keep it visible
Some of Pichler’s teams’ definitions of done have, e.g., been specific about expected test coverage metrics.
Daily scrum
The product owner should go to this meeting, and share information on what the product owner has been doing and will do next.
Use the daily scrum to provide context to the team and to identify work that the team suggests is done. Engage in reviewing, providing feedback on, validating doneness of that work in real time during the sprint. (Do not wait until the sprint review meeting. It should not be a surprise at that meeting to discover that work is or is not “done” per the definition of done.)
The product owner must not interfere with the team’s self-organization. This is important and nuanced and difficult.
- Do not assign tasks
- Do not comment on the progress achieved by individuals
- Do not tell the team what to do
Try asking questions.
Listen for impediments. The ScrumMaster is responsible for engaging with and addressing impediments raised by team members via the daily Scrum, and the product owner is responsible for being available to the ScrumMaster and to the team to be part of the solution to those impediments. Maybe the product owner can clarify a requirement or connect someone to a customer or domain expert or verify an alternative approach will fulfill the business need. At the least the product owner can learn something about the product from the impediments encountered in developing it.
Sprint backlog and sprint burn down
Pichler talks about keeping the sprint backlog and burn down chart up-to-date, with team members ensuring the things they touch are updated at least daily.
These artifacts primarily serve the team as the team works towards its commitment of delivering the sprint backlog scope.
These artifacts are useful to the product owner to understand what is going on, but should not be reported outwards out of the team. The team is self-organizing as to its internal processes within the sprint — the larger organization is welcome to observe and then primarily interfaces with the team through the results of the sprints, through sprint review.
Updating the remaining effort per sprint backlog entry
A wrinkle: Pichler mentions the team updating sprint backlog entries to record how much effort is left with each task.
I was on a Scrum team that actually did this once upon a time, where sprint backlog entry sub-tasks had estimated hours associated with them. (Yes, hours rather than story points are a sin; yet, we were billing by the hour, so hours were actually the currency management and the customer really cared about. Using hours in this way actually worked great so long as everyone was understanding that estimates are always wrong (and are always wrong in the under-estimated direction)).
This is neat in that the sprint burndown chart becomes more useful for projecting whether the team will deliver the sprint backlog and helps the team to see what scope is taking or took more effort than expected (and if things are going slowly, allows the product owner to engage with the team to advocate dropping the least-important sprint backlog scope or even dropping in-progress sprint backlog entries that are proving more expensive than was expected or is justified by their value).
Reporting on actual vs estimated then helps to identify interesting items for consideration in retrospective and the team learns to estimate better, even when committing the Scrum sin of estimating in hours. Faced with enough sprints where tasks actually took more hours than were estimated, the team starts raising those estimated hours up towards reality.
Sprint Review
Invite stakeholders to the review, and get them to actually come.
- Sales
- Marketing
- Technical support
- Customers
- Partners
Keep prep work for this meeting to a minimum. The team is delivering working software every sprint, right? So demo the working software. If you can’t demo the working software, how do you know it’s working?
Wireframes, slide decks, Word documents, requirements specifications — these are not working software. Minimize or eliminate showing them in the sprint review.
This is not a show. The purpose of the meeting is not to impress, and it’s especially not to unduly impress. The purpose of the meeting is to be transparent and reality-adhering.
The product owner should kick off the meeting by comparing the done, complete, working-software product increment delivered in the sprint to the sprint goal. Thoroughly review the product increment. Demo it and test it live.
Only accept as done product increment that actually really fully fulfills the definition of done and actually really fulfills the acceptance criteria, the conditions of satisfaction, and delivers the value the story expected to deliver. Never accept unfinished or defective items.
This is hard, and hard to get right. It helps a lot if you’ve been thoroughly available and have reviewed and accepted sprint work product during the sprint so that there are no surprises for the team at this meeting.
Don’t be a jerk. The challenge is to without ego and absolutely without putting any individual on the spot, help the team to understand and fulfill its commitments. The team collectively and no individual is responsible for fulfilling the commitments of the sprint, and when they’re not fulfilled, the thing to do is to be honest and forthright about that. Always always always address the entire team.
Ask the stakeholders for feedback.
- Do they like the progress?
- Now what we can all see the working software, is this going to be successful or does it need adapted?
- Uncover new requirements, or discover that existing product backlog entries are obviated.
Manage stakeholder expectations about what they are seeing, about how close it seems to be to release, about how much room there is to adjust it before release.
The team will not necessarily and should not necessarily do exactly what the present stakeholders suggest. The commitment is to listen, to understand the feedback, to respect the feedback, to welcome the ideas. The team will then digest and respond to that feedback, and maybe that will lead to making exactly a change suggested via this feedback, and maybe the feedback with synthesize with other ideas to yield something that seems more promising.
Sprint retrospective
Via the sprint retrospective process, the team inspects how work is carried out and identifies ways this can be improved.
The product owner should attend the sprint retrospective and be available to be part of the solution in process improvements.
Common mistakes
Still my favorite part of this book : Pichler’s calling out anti-patterns and pitfalls.
Anti-pattern: Bungee product owner
In this anti-pattern the product owner shows up at sprint planning, disappears, and re-appears for the sprint review, having been unavailable and absent in between.
Your product owner responsibilities must be your number-one priority.
Anti-pattern: Passive product owner
In this anti-pattern the product owner passively watches the show of the sprint review. This is broken.
The purpose of the sprint review is to figure out together what real progress has been made and what needs doing to create a successful project. The product owner must actively contribute to this to help the product evolve fruitfully.
Anti-pattern: Unsustainable pace
In this anti-pattern the team undertakes an unsustainable pace and succombs to exhaustion.
Respect the team and the self-organization. Improve process and pace, but never by pressuring people to work more hours harder.
Anti-pattern: Smoke and mirrors
In this anti-pattern, the sprint review is a Powerpoint-driven spectacle of smoke-and-mirrors vaporware.
Artificially impressing is not the point of the sprint review.
The point of the sprint review is to discover and remind of the reality of accomplished progress and what is yet to be done.
Demo only really done working product.
Anti-pattern: Reporting up the sprint burndown
In this anti-pattern, internal team-facing sprint burndown artifacts are reported outward as if they were status reports. They are not. The expected out-ward-facing artifacts are roadmaps, release plans, release burndowns, sprint reviews, and release notes.
If you need more within-sprint status updating outward, either realize you don’t need this (you don’t need it), or shorten the sprints so that the sprint review can fulfill this need.
No one outside the team actually needs status updates on an interval more frequently than every two weeks.
Read the book
It’a a good book, you should read it.
While I hope my summary is helpful, it misses nuance and examples from the book itself.
This post is part of a series
This post is part of a series of posts about chapters in Roman Pichler’s Agile Product Management with Scrum.
-
Chapter 5 : Scrum meetings (this post)
Acknowledgements
Cover image : from Richard Rutter : via CC-BY-2.0 .