Editor’s note: This blog post was originally published in August 2016 and has been completely revamped and updated for accuracy and comprehensiveness.
This article is an excerpt from our new book. For the full guide to building a collaborative software team, pick up your free copy!
You’ve set up the perfect Workspace, customized your labels, refined your backlog, perfected the art of the issue, and conquered time estimations. Go you!
But important questions must be answered before you start sprinting. How much work can you actually tackle? Can you really ship anything in the next two weeks? What issues should you choose?
Accept that, especially if this is your first foray into an agile-ish process, you won’t have all the answers. Time, budget, and quality are fixed, and now it’s time to predict the scope of work your team can accomplish. The only way to answer these questions is to talk to your team.
At ZenHub, we generally stay away from capital letter project methodologies – that is, Scrum, Kanban, or even “Agile”. Our philosophy to product development is closer to post-agilism, whose manifesto is pleasingly simple:
If it works, do it. If it doesn’t, don’t.
With this in mind, here’s how we approach a (lowercase) sprint.
Milestones = sprints
Remember, when we talk about GitHub Milestones, we’re talking about sprints. We use the terms interchangeably.
In GitHub, a sprint backlog is created by adding a Milestone to the issues in your Backlog pipeline. Issues in your backlog pipeline without a Milestone are your ‘product backlog’ – these are things you’ll eventually tackle.
Choose a due date for your Milestones that aligns with the end of your sprint. Typically, that’s two or four weeks. 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.
What to include in a sprint?
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
-
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 backlog pipeline to the sprint backlog – meaning it has a Milestone attached – 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.
So how do you decide what issues belong in your Milestone?
How much work goes into each sprint?
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 (a concept we discussed in our guide to software estimation.) 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!
However, if your team is standing firm on time estimates, you can use some simple math to put together your first sprint. First, add your estimated issues up until they fill up your sprint’s time allocation. For example – in an ideal world, each team member is capable of completing 70 hours of work during a two-week sprint. With five team members, that adds up to around 350 hours of work.
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.
To accommodate for variables like inaccurate estimates, unexpected requirements, and real-world realities, one-third of the sprint time is left unassigned. For a five-person team, this means you'd assign roughly 230 hours per Milestone – not the 350 hours quoted in the “ideal world” scenario.
Remember: your primary goal during a sprint is to make sure each assigned issue is fully delivered.
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.
Only your developers 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.
Think about it. As a user, what would impress you more? A bunch of tiny improvements to a handful of features over the course of eight months, or big obvious improvements to one feature at a time? The latter is certainly more noticeable, and gives a clear message: your team is frequently shipping high-value improvements.
The value of sprint velocity
When you assign issues according to how long you think it will take, you are taking a guess at your team’s projected velocity.
You only have a rough idea of your team’s velocity when you first start a sprint. Over time, you can track your team’s actual velocity: the actual rate it takes your team to get work done. Knowing your team’s actual velocity enables more accurate estimates and, as a result, more effective sprints.
Unfortunately, a single milestone can’t really be considered an accurate assessment of your team’s velocity. It will take a few months before you have the data necessary to make useful assumptions.
When you've been through a few sprints and have some historical data, velocity charts become a useful tool.
Using Velocity Charts
Where burndown charts show how things are going, velocity charts show you how things went.
People, as a rule, overestimate how much work they can do and underestimate the complexity of the work they’re doing. Velocity charts display your teams historical speed of work and therefore, provide a precise picture of what your team can really handle. The ZenHub Velocity chart will populate with the 7 most recent closed Milestones, and display the next 3 upcoming Milestones.
Note that we measure team velocity instead of individual productivity to sidestep these estimation shortcomings, and to build a culture of healthy collaboration.
In The Agile Samurai, Jonathan Rasmusson explains:
When we create plans based on our team’s velocity, we are making a commitment as a team. We’re saying, “We, as a team, feel we deliver this much value each and every iteration.”
This is very different from measuring individual productivity— which leads to the dark side of project management. If you want more bugs, more rework, more miscommunication, less collaboration, less skill, and less knowledge sharing, then by all means, promote, highlight, and reward individual developer productivity.
Just understand that by doing so, you are killing the very spirit and behavior we want to foster and promote on our projects: sharing ideas, helping each other out, and watching for things that fall through the cracks.
Reason enough for us.
Now the fun part begins: are you ready to ship some code?