Sprint Best Practices
One of the main benefits of working in an Agile fashion is that you can shift your product priorities as the landscape around you changes.
While this benefit enables you to be flexible, it’s often difficult to keep sprints updated to reflect ever-changing priorities and seamlessly communicate these changes across the organization.
So, let’s talk about sprint best practices. I’m assuming that you’re using some ticket management system such as Jira, Asana, Trello, Pivotal Tracker, etc.
Ticket Ordering
First, ensure your sprint is loaded in absolute priority order.
You get no ties, and you get no buckets. Every ticket should be strictly prioritized. The order of the tickets in your sprint is exactly the order that your development team should execute against.
In practice, this is difficult and controversial. You might have an urgent bug that needs resolution but also a mission-critical long-term initiative, both of which are in the same sprint – they both might feel like the highest priority.
Do yourself and your team a favor by picking one to move up to the highest priority. Even if it’s an arbitrary choice, it helps keep the team focused.
Trust me, I’ve learned from personal experience – having a single highest priority enables tickets to be resolved faster, and hence you can accomplish more in a given sprint.
As a product manager, you determine focus and prioritization for the rest of the team – so if you can’t provide clarity for your stakeholders and teammates, you’ve let them down.
Sometimes, critical or blocker bugs get filed into the sprint. This is completely natural – as a product manager, you must constantly deal with crises and manage change. But what happens is that these tickets sometimes sit at the bottom of the sprint. When tickets are out of order, the team is forced to review the entire sprint on a daily basis to determine priorities, rather than working from top-down.
Save your team the struggles of such mental overhead, and order all of the tickets correctly. By force-ranking priorities, your team knows exactly what’s next to tackle without needing to review the entire sprint.
Ask around the product community to get some additional tips on the process to maximize your understanding of it.
Bandwidth
Second, ensure that your sprint is not overloaded.
You should only commit to delivering sized tickets. The particular sizing mechanism itself isn’t the important part (e.g. story points or estimated work hours). The fact that you sized the ticket is what’s important.
If you can’t size a ticket, it probably means that you don’t have the necessary clarity in the requirements, or that you aren’t working at a granular enough level. Figure out whether you need to split the ticket into more tickets, or whether you need to groom the ticket further.
Furthermore, ensure that tickets in the sprint do not go past the team’s total bandwidth. This includes holidays, sick days, out-of-office days (OOO’s), and other bandwidth constraints.
Be honest with yourself and your team. You’re doing everyone a disservice if you overcommit in your sprint. Reflecting the true state of your bandwidth sets clearer and more accurate expectations throughout your entire organization.
What happens if you don’t accurately reflect the bandwidth of your team within your sprint?
Your team will be stressed out. Every sprint, tickets from past sprints will flow into the next sprint, which means that your team will never get any closer to completion. It’s a stressful situation to live in. Trust me, I’ve been there before with my teams – it causes headaches and heartaches.
Your team will also feel as though they’re never allowed to take time off to take of themselves and to meet their other commitments. If you don’t consider your team’s actual human needs, your team will dislike working with you, leading to lower productivity over time, and increasing the possibility of churn. Ramping up new teammates is insanely costly – don’t lose the talent that you already have.
Your stakeholders will be confused and frustrated. When you say “I’ll do it this sprint”, they expect it to be done by the end of the sprint. While saying “yes” to every request feels good – you’re being helpful and understanding! – you wind up overburdening your team and disillusioning your stakeholders.
Saying “no” feels bad in the short term, but actually winds up building trust over the long term. By saying no, you signal to your stakeholders that when you commit to something, you mean it.
Active Re-Prioritization
Third, actively maintain the health of your sprint by regularly checking that your tickets are still ranked correctly. Business context changes, and therefore your priorities will change too.
If you forget to review the priority of your tickets, you’ll find that you’re delivering lower impact items and missing higher impact items.
To be entirely honest, I sometimes forget to review priorities mid-sprint. And each time I forget, our team loses impact.
As a product manager, remember that your entire goal is to accelerate the magnitude and speed of positive impact. Therefore, priority review is a core responsibility for all product managers – yes, even while the sprint is in progress.
Sometimes people will file tickets directly into a sprint without your guidance as a PM, which causes loss of prioritization. They’re not being malicious – they just might not know how your team works.
Make sure you preserve all the hard work you did during sprint planning, and maintain the priority of your tickets, especially when others try to add tickets into your sprint!
I’ve personally found that reviewing ticket priorities daily actually takes less time than reviewing on a weekly basis, since context helps you to make relevant decisions. Entropy increases over time – and you must invest mental energy to reduce this entropy so that your priorities are still ordered correctly.
Structure
Provide clarity to your stakeholders on when your sprints will end, and what you expect to deliver by then, in what priority.
I’ve found that by naming, numbering, and dating my sprints, I can communicate much more clearly to non-technical stakeholders.
For example, name your sprint something like “DEMO Sprint 2, 2018/04/27”. Inform your stakeholders on your naming convention, and when you expect to end the sprint. That way, when you get asked about the priority and the progress of their requested work, you can easily point to your sprint board as the single source of truth.
Furthermore, whenever you do need to kick something out of the sprint and into the backlog (which also needs to be maintained to be healthy!), you’re able to provide more clarity into the shifts in delivery dates.
Say you kick out a ticket for 2 sprints – your stakeholders know exactly when you’re planning to deliver that functionality or fix because they know which sprint it’s in and what the end date for that sprint is.
Summary and Takeaways
Sprint health is just another way to measure how well your team and your organization are communicating. Sprint best practices maximize the flow of relevant information.
To ensure that your team is on the same page, ensure that your tickets are ordered in strict priority order, so that there is no ambiguity about what’s next up to tackle.
Ensure that you treat your team fairly and that you allocate only enough tickets within a sprint to complete them all. This not only prevents team burnout and stress but also provides more accurate forecasting to you and the rest of the organization.
Re-prioritize your tickets regularly.
Use consistent naming conventions within your sprint to provide clarity across all stakeholders.
While it may not feel particularly sexy or impactful to act as the janitor of your sprint, you’ll find that observing sprint best practices is one of the highest-leverage activities at your disposal.
Practice sprint hygiene regularly, and you’ll find that your team and your stakeholders will enjoy working with you more and more!
Have thoughts that you’d like to contribute around sprint best practices? Chat with other product managers around the world in our PMHQ Community!
