A question which inevitably arises when kicking off a new agile Scrum project is “How many stories or story points should we commit to in our first sprint?” It’s all well and good relying on your team’s track record once you’ve achieved a predictable enough velocity after a number of sprints, however at the start of a Scrum project, the problem of sprint capacity planning becomes a little more tricky since you lack sufficient data to make an informed decision.
A Few Incorrect Solutions to this Problem
I’ve seen many misguided efforts to solve the problem of early sprint capacity planning, such as
“Well a good benchmark is 50 points per person per sprint”
“Let’s workout roughly how many hours a point is worth, and how many hours we have as a team, then go from there”
“Let’s just pick anything for this initial sprint, it doesn’t matter as the first few sprints will always be way off”
Let’s go through these misguided efforts one by one and understand why they’re sub-optimal solutions. The first idea of using 50 points is bordering on madness. A story point has no meaning outside of a given team. Story points are estimates of the effort required to complete a given story in the context of a particular team, often based on an initial reference story which is assigned a sensible arbitrary point value. Therefore, 50 points to Team A means absolutely nothing to Team B, and thus picking a value out of thin air simply makes no sense.
The second attempt, though not nonsensical like the first, is also inadvisable and threatens the integrity of future estimations. By allowing your team to picture a mapping between points and hours, you are setting a dangerous precedent for subsequent estimation sessions where people may continue to adopt this mindset, particularly if your team is new to agile and coming from a waterfall background. There’s nothing wrong with using time based estimates on Scrum projects, but if you say you’re going to use story points then don’t just use time estimates masquerading as points. Again, keep in mind that story points are a measure of effort, not a measure of the length time a task will take to complete. Even if you promise yourselves “we’ll just do it this once”, it’s a slippy slope to go down and sounds an awful lot like “I’ll just have one more slice of cake, and then I’ll stop”, which I can confirm from my vast experience on the subject simply doesn’t work.
The third attempt is just accepting defeat without even trying. The frequency with which I hear teams laugh heartily at the chaos when recalling the early days of their project often confuses me. I don’t believe there is anything preventing a good team from getting it right from the start. Agile places an emphasis on trust and the knowledge of team members, so try to draw on the experience of your team and trust their ability to be successful from the word go!
The Correct Solution to the Problem
In my experience, the most successful solution is actually one of the simplest. To arrive at a reasonable amount of points to take into your first sprint, all you have to do is start running through the stories in the backlog in descending order and ask the following question to your team
“Are we confident we’ll be able complete this story as well?”
Controversial though it may seem, I actually advocate forgetting the story points altogether at this point (cue cries of Heathen! and Blasphemy against the Manifesto!). Instead, just use a bit of common sense and honesty. Look at what you’ve accepted so far and ask yourselves whether you can honestly say, with a reasonable degree of confidence, that after X weeks - where X is your chosen sprint length - your team will have been able to complete the already accepted stories plus this additional story which is currently under consideration. Note the use of the word confident! Don’t set yourselves up for a fall by being overzealous. Once someone answers “No” with an acceptable justification, stop there and you’re done. It’s important to recognise that for this method to work, all your team members, including those who are more junior, need to feel able to exercise their freedom of speech if they have any doubts whatsoever. Also, in your first sprint planning session you should have at least completed the following pre-requisites for using this strategy:
- Discussed, explored and further prioritised the backlog
- Chosen a ‘reference story’ and assigned it a story point value to use as a baseline for estimating other stories
- Used ‘planning poker’ to estimate the effort required in terms of points for a reasonable number of stories towards the top of the backlog
I really can’t stress enough the importance of putting faith in your team members and drawing on their expertise and knowledge to drive the decision making within your team.
Closing thoughts
I like to keep in mind a few key points at all times when my team is trying to decide what we’ll commit to early on in the project:
- Don’t become a slave to story points. Successful agile teams rely on the quality of their team members, especially those who can draw on their past experience to inform their future decisions.
- Be conservative at first. Inevitably at the start of a project there are going to be unforeseen issues that need ironing out. Your code reviews will take longer, you’ll have to write more scaffolding and boilerplate code, your CI tooling might fall over etc. All these issues will most likely eat up more effort from your senior team members and reduce your effective capacity
- Do not forget the human aspect of software engineering teams. Don’t set unachievable goals that will damage team morale — there’s no better feeling than finishing a sprint and knowing that you nailed it as a team. Getting off to a good start will set the tone for future sprints
Once you’ve completed your first sprint, you’ll be on your way to understanding what your team is capable of accepting into a sprint. Even once you have an idea of your average velocity and can start basing sprint capacity on previous sprint data, it’s always valuable to take a step back and a realistic look at what you’ve committed to and consider whether it’s achievable.
