Kanban, Scrum, SAFe, LeSS—regardless of the methodology 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 framework for how you work, we share structured, yet flexible ways of working.
It starts with figuring out a common guiding mission or purpose
Most frameworks in Agile are quite prescriptive, but we think a bit differently! We believe teams should be working as one collective unit, moving away from individual performance or concepts of "my part". Instead, they should focus on how everyone is contributing to the same goal, or end state.
While you may have multiple pods or squads that make up a team, everyone should be working on the same set of data, information, and shared understanding of what each pod/squad is working towards. In practice, this means a few things!
- Come together for sprint planning: Team members then get an opportunity to self-organize on the actual assignment and commitment of work, discussing opportunities to find shared opportunities to collaborate.
- Share daily stand ups: Each team has their 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 pubic.
- Have a central Product backlog, that gets prioritized towards the same 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.
An important question teams should be constantly asking themselves is, "How much work can we actually tackle? Can we really ship anything in the next two weeks? What issues should we choose?". To answer these questions, you have to have a unified Backlog that is based on your common guiding goals. When pods / squads 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).
At ZenHub, we encourage teams to adopt a framework and methodology that best suits them. Our philosophy to product development and the way teams work closer is similar to that of post-agilism:
If it works, do it. If it doesn’t, don’t.
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 spend that much time worrying about being Agile and following all of the rules, you might also find yourself slipping further away from being collaborative and iterative!
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.
We recommend having 2 different concepts of a Backlog for the team to work from to communicate more effectively
- Work that is sprint-ready, but not yet accepted and planned into the upcoming Milestone (development backlog)
- And work that has been committed to, and accepted into the upcoming sprint (sprint backlog)
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 accomplish 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
When it comes to a timeframe for your Milestone/sprint, we recommend a two week cadence. You should 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.
Not sure what to include in a sprint: here's some tips
To figure out what Issues should be added to a Milestone, you need to have a healthy product backlog. "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. Learn to estimate effectively
A user story that addresses 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
Priority according to the Issue’s business value
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?
We like to think of sprints in relation to goals. A "sprint goal" is the amount of work your team agrees can be completed within a sprint. The goal should be a collective effort; everyone should have a say.
The unpredictable nature of time estimates is the reason why we prefer to use story points instead. 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 weeks, 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 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 goal during a sprint is to make sure each assigned issue is fully delivered and the team is united behind the same goal.
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 some theme for each sprint. Not only do themes help set a clear goal to move toward, but they help keep your users happy.