This is a guest blog post by my colleague: Michelle Pauk, Enjoy!
Scrum is all about rhythms. Teams that are successful with Scrum establish a sustainable cadence for collaborating with each other. Each of the sprint ceremonies help us move toward our goal, and remind us what’s coming next.
Scrum is pretty straightforward about how to establish the right rhythms for the team, but organizing your work as a product owner is a little murkier. You know that sprint planning happens every two weeks, but what do you need to do to prepare? Your team does backlog refinement for an hour every week, but how far in advance do you need to start working on stories to make that meeting worthwhile?
In this article, I’ll share the rhythms that have worked well for me as a product owner. The Scrum ceremonies act as a trigger – a reminder that there’s something I need to do. I’ll organize this article by those triggers, and we’ll work our way backward to see what we need to do to prepare.
Sprint Planning
Begin with the end in mind
For your team to be successful in sprint planning, you will need to come prepared with the following:
- Sprint goal
- Your prioritized list of stories for this sprint
If your team has gone through a release planning exercise, the sprint goal should support the goals of your release. You may have even drafted rough sprint goals as part of release planning. The goal you articulate should be supported by the stories that you are asking the team to focus on in the sprint.
If you haven’t done release planning, you should still take the time to define a clear sprint goal. The goal should be high-level (not just a list of the stories you plan to work on) and illustrate the outcome or impact of the sprint. When your stakeholders read the sprint goal, they should know what to expect at the sprint review. When your team reads the sprint goal, they should understand what’s most important to focus on during the sprint.
Get regular input from your stakeholders
When writing your sprint goal, it’s important to confirm your direction with your key stakeholders. I like to schedule a regular stakeholder meeting immediately following the team’s sprint review. At this meeting, I confirm the priorities for the next sprint (which will be planned the next day) and gather input on the direction for the following 2-3 sprints.
There are two things I balance when working with stakeholders on the direction for our upcoming sprints. The first is being responsive to feedback; the second is respecting what my team and I need to craft thoughtful, valuable solutions. So, while I want to respond as quickly as possible to my stakeholders’ input, I also want to ensure the team and I have enough time to consider the implications of what we’re doing and how best to proceed. The key here is being responsive without slipping into the dangers of being reactive.
One thing that helps me achieve this balance is keeping 2-3 sprints’ worth of groomed backlog estimated and ready to go at all times. If we get some unexpected feedback at the sprint review, I might not be able to implement the new requests in the next sprint, but we should be able to pull in valuable work from the ready backlog. If the direction changes significantly and I need time to rework the feature stories in my backlog, I can always ask the team concentrate on technical debt stories in the next sprint.
Take time to prioritize
In addition to a goal for the sprint, it’s your responsibility to bring a prioritized list of stories to the planning meeting. Everything on the list should meet your team’s definition of ready. Everything should have been estimated by the team.
Take the time to prioritize the stories. It is unhelpful to tell the team “well, it all has to be done, so it’s the same priority.” All the work may need to be done, but it is your job to understand the business value and risk of each story and ensure the team is working on the highest value items at any given time. If you make prioritization a daily habit, then preparing for sprint planning is just a simple matter of reviewing and confirming your list.
Backlog Refinement
Set your pace
The goal of regular backlog refinement is to prepare your team to plan their next sprint and be able to pivot quickly if things change. The pace varies from team to team, but the goal should be steady replenishment of the backlog. Let’s say your team has two-week sprints and a velocity of 20 points per sprint. To keep pace with them, you’ll want to bring roughly 10 points’ worth of stories to your weekly backlog refinement meetings. Of course, you won’t know how many points the stories are until the team sizes, but you can make some rough guesses.
Alternatively, you might aim for enough stories to fill an hour-long discussion. If your team sticks to a maximum timebox of 10 minutes per story, then six to eight stories should be sufficient.
Send an agenda the day before
Depending on where a story is in the writing process, you might have different objectives in mind for the refinement conversation. Be clear about what those are when you introduce the story. Do you need an estimate, or are you looking for input on the acceptance criteria?
It’s good to get in the habit of sending your team the agenda of stories to review the day before the refinement meeting so they have a chance to look them over. Include the story titles and links to the full stories in your backlog. A sample agenda might look like this:
Hi Team,
We have six stories to discuss in our refinement meeting tomorrow. We’ve looked at Stories 1-3 before, and I’d like to estimate those. For the last three, I’d like to work on defining acceptance criteria together. Here are the stories:
Story 1: User Profile Picture
Story 2: Contact Information
Story 3: Unlock Password
Story 4: Report Generator
Story 5: PDF Print View
Story 6: Email Notification
Love,
Your Product Owner
Give yourself plenty of time to write, and even more time to revise
Everyone approaches story writing differently. I like to work in batches because I need to get into a “flow” to really think creatively about the stories. My preferred approach is to block off 3-4 hours every week (a full morning or afternoon) to prepare stories for the upcoming refinement meeting. Throughout the week, I keep a running list of the stories I plan to work on in my OneNote. Then, when my writing time comes, I put my headphones on, settle in, and get to work.
Most professional writers will tell you that the bulk of their process is spent revising their work. I think user story writing is no different. The length of a user story is deceptive. Well-written stories are like good poems – they are powerful because they contain only what’s essential, and nothing more. This is extremely hard to do! Give yourself plenty of time to draft your stories, let them sit, revise, ask for feedback, revise, let them sit some more, revise again (you get my point…). If you are in the habit of “cramming” the night before sprint planning or backlog refinement just like you did in college before an exam, stop doing this now. You can scrape by that way, but it’s hard to bring your best ideas to the team if you don’t give yourself time to pause and reflect. Quality is a team effort, and that starts with you and the quality of the stories you bring to the team!
Okay, now I’ll step down from that soapbox.
If you choose to work on stories in small batches like I do, it’s good to consider whose input you’ll need before, during, and after your writing session. If you’re working on a new feature for a particular stakeholder, you might want to schedule a meeting with that person soon after you’ve drafted your initial ideas. This allows you to get early feedback before bringing those stories to the team. Alternatively, you could invite that person to write the stories alongside you in a pair session.
Pair sessions work well for writing up technical stories, too. Often I’ll work with my developers and testers to write up a technical debt story together. I’ll summarize the business impact and risk for the story, and ask the developers and testers to write any technical specifics they want to remember later.
Sprint Review
If you want to throw a good party, you better invite the cool kids
The sprint review is your main opportunity to get input from stakeholders. Preparing for a sprint review is the entire team’s responsibility, but there are some specific things you can do to help ensure your review is effective.
The first thing is to make sure your key stakeholders plan to attend. I have had good success with scheduling a standing meeting for the sprint review, so it’s a constant entry on the calendar. I also make it a habit to update the meeting invite with a fresh agenda for each review. I include:
- The sprint goal
- The sprint start and end dates
- A list of the planned user stories and other backlog items
I favor the “invite the world” approach to sprint reviews. Since not every sprint review will be immediately relevant to everyone on the invite list, I want to give them enough information to decide for themselves if they would benefit from attending.
I do not take this “self-serve” approach with all stakeholders, however. If my team needs feedback from specific people, I will personally invite them to the sprint review and ensure they will be able to make the time we’ve scheduled. If they can’t come, then we reschedule. The primary purpose of the sprint review is to get meaningful feedback, which you can’t get if the right people don’t show up!
Creating Your Schedule
To be successful as a product owner, it’s vital to get into a rhythm that allows you to support your team, involve your stakeholders, and think creatively. Carve out time for thinking, reading, and daydreaming in your schedule, and respect your team’s need to do the same. Software is so interesting because we rarely know what the solution will look like when we start out. And since we don’t quite know what that solution is, we can’t chart a linear path to “done.” You and your team need time to wander and collect ideas. My most innovative product ideas come from smashing together concepts that may appear to be completely unrelated, and this always happens in my open think time. I make that time a priority because it’s how I produce my most valuable work.
To get you started, the post header photo is a sample schedule with key activities noted. Experiment to figure out what works for you and your team.
Good luck!
Michelle.