Kanban, Scrum, SAFe, LeSS—regardless of the framework you practice or borrow from to guide the way your team works, collaborates, and develops software there's a common understanding that you're one team. To adopt a good practice for how you work, we share structured, yet flexible ways of working.
It starts with figuring out a common guiding mission or purpose
We believe teams should be working as one collective unit, moving away from individual performance or concepts of "my part". They should focus on how everyone is contributing to the same goal or end state.
This applies to scale as well.
If you have multiple teams working on the same product, everyone should be working on the same set of data, information, and shared understanding of what each team/pod/squad is working towards. In practice, this means a few things!
- Come together for part of sprint planning: Teams then get an opportunity to self-organize around the top items in the product backlog, minimizing dependencies, distributing work based on skills and interests, and finding shared opportunities to collaborate.
- Create a clear Sprint Goal for each team: The first step in Sprint Planning is to create a SMART goal for the upcoming sprint: why is this sprint valuable? This creates more focus and purpose for developers within each team to work together, and allows other teams understand how they align with each other.
- Share daily stand-ups: Each team has its own roadblocks, dependencies, and action items but you're all coming together under a common thread. Coming together to discuss roadblocks and action items means more opportunities to collaborate in public.
- Have a central Product backlog, that gets prioritized towards the same product goals.
- Share learnings in sprint reviews. Teams get better if they learn from each other.
- Come together for retros. Not just at the end of every sprint should you review what's working and not, but take time at least once a month to retro as a group to discuss your process, team workflow, or in general what is working and not. While not mandatory, it’s a great practice to implement.
An important question that teams should be constantly asking themselves is, "How much work can we actually tackle? Can we really ship anything in the next sprint? What issues should we choose?". To answer these questions, you have to have a unified Product Backlog that is based on your common guiding product goals. When teams work independent of each other, it's easy to become divergent (working on streams of work that conflict or otherwise don't have a chance to overlap in impact).
When teams are too prescriptive or worry about following 'rules' to a T, it means you might be missing the nuances of how your team actually works together. No two teams, even in the same organization, are the same. How you jive as a team needs to be taken into account when shipping work.
When you’re adapting to ever-changing teams, needs, processes, projects you're focused on a common agile concept of Kaizen—the practice of continuous improvement.
Everyone's day-to-day, your customers' needs, and even team needs change, and that's what rallying behind a common shippable product is all about.
With this in mind, here’s how we approach sprints
In GitHub and ZenHub, sprints are GitHub Milestones. As ZenHub is an extension of GitHub, when we talk about GitHub Milestones, we’re talking about sprints. We use the terms interchangeably.
2 different concepts of a Backlog for the team to work and communicate more effectively
- Development backlog: Work that is sprint-ready, but not yet accepted and planned into the upcoming Milestone.
- Sprint backlog: Work that has been committed to, and accepted into the upcoming sprint.
Prioritize the development backlog from top-to-bottom, by importance. Everything at the top should be spec ready, have a clear acceptance criteria, and be estimated. We recommend having bi-weekly backlog grooming sessions to keep these Issues fresh, check priority, and ensure work is estimated upfront. Keeping this pipeline prioritized helps teams understand the most important issue to work on next should everything in the sprint be finished ahead of time!
Your sprint backlog should also be prioritized. This helps the entire team know the most important work that you’ve committed to accomplishing first in the sprint. This might be a high priority bug or a back-end issue that is blocking front-end work.
A note on a recommended sprint cadence
A few words about the length of a Sprint since it will impact how you set up your sprint schedule.
The most popular length is two weeks. However, the rule in Scrum is that the sprint should be no longer than a month. The length of the Sprint will depend on a few factors that you should take into account.
The most important is that the team has to be able to ship something usable in that time period. If you can’t, then your issues are too big and you should break them down into smaller pieces. More on how to best structure Issues, tasks, and projects here.
Not sure what to include in a sprint: here are some tips
To figure out what Issues should be added to a Milestone, you need to have a healthy product backlog and a clear sprint goal. "Having a prioritized list of your high-level requirements or your product backlog is a key input going into the first agile sprint," says agile consultant Yvette Francino.
That means your issues should have:
- Estimates that you and your team decide on together. While not mandatory, estimates can be helpful.
- Definition of the who and why of a task, plus any requirements. Don’t worry about adding too much detail yet – you’ll discover more information as soon as you start your Milestone
- Order according to the Issue’s business value
A sprint goal will help define what issues should be added to the sprint. Once an issue moves from the development backlog pipeline to the sprint backlog —meaning it has a Milestone attached, is estimated, and has a shared team understanding—it’s ready to be assigned to your team. If you've done a good job organizing your backlog, team members can assign themselves; otherwise, the product owner can do it.
How much work goes into each sprint?
There are a few factors to consider when deciding how much work to take into each sprint. The definition of "done" on the level of the product will give a clear understanding of what needs to be done for every work item overall. A team’s past velocity and estimated capacity will help with forecasting.
The unpredictable nature of time estimates is the reason why we prefer to use story points. Using story points, we are able to estimate relatively. Since your tasks aren't tied to real hours, you're able to reduce complexity and account for sick days or vacations.
There's no perfect answer for the amount of work to include in your first sprint. You're probably, almost definitely, going to get it wrong the first time. If the number of story points in your first sprint feels about right, then stop worrying and start sprinting. After a couple of sprints, you'll have enough historical information to inform your next sprint. Don't stress about it!
Because you don’t know what your average sprint velocity is, it’s easy to over-commit in the early stages. (Don't worry too much if that happens. If necessary, you can always adjust the scope.) Likewise, you don’t always know what unforeseen tasks will become necessary during a sprint – and thinking about it too much is a great way to not get any meaningful work done.
Remember: your primary objective during a sprint is to make sure each sprint is achieving the sprint goal and having fully complete work at the end, represented by a working usable product increment.
A few extra notes about your first sprint planning meeting
If you've done everything right, you should already be entering your sprint with estimated issues and a prioritized backlog. Does that mean you have all the information needed to move forward? Hardly. You might not have all the information about dependencies, conflicts, or the urgency of certain bug fixes. That's what your sprint planning meeting is for. It should be a chance for your team to advocate for the inclusion of certain Issues over others.
That doesn't mean your sprint is a free-for-all. Quite the opposite: you should make it a best practice to stick to an agreed upon sprint goal for each sprint.