Before I get to how much capacity there is in a sprint, let’s take a look at the flow. If you are doing Scrum, you are probably familiar with a diagram that looks something like this:
When it comes to figuring out what day to start on, and when each ceremony should be done, I thought it would be nice to see it all laid out and explained in a calendar format. Here is my calendar view (there are others) of the ceremonies for 2-week sprints.
No matter what numerical day of the month it is, I recommend starting sprints on Wednesday or Thursday. The reason is simple: it is easier to get everyone to attend Sprint Planning, Sprint Review and Sprint Retrospectives when they don’t fall on Monday and Friday’s. If you are experiencing difficulty in attendance to these ceremonies when they are on Monday’s and Friday’s, consider moving the first day of the sprint to Wednesday or Thursday. With continuous delivery, you can promote code to production on Thursday, rather than on Friday. Thursday promotions to production allow first day support to happen on Friday, rather than the weekend!
Day 1 – Sprint Planning – The Product Owner has the stories prioritized for the upcoming sprint all ready and presents them to the team. The team will size (if not already sized), discuss the design and tasks for the stories, and commit to what they can get done. Allow adequate time for the team to work together to complete tasking and commit to the work.
Day 6 – Grooming – While the Product Owner is always refining stories and getting them ready for the team, they must also meet with the team on a regular basis to get their input into upcoming stories. During the grooming meeting the team can let the Product Owner know what additional information might be needed to consider the story ready for a sprint. If there is enough information for the team to size stories, this is a great time to do so.
Day 9 – All Code in QA Environment – I know this isn’t a ceremony, but it is worth pointing out. Stories should be between ½ day – 2 days of work, this means that stories are flowing into QA throughout the sprint. By Day 9, if you have a lot of code still in process, how will it be tested in time for the Sprint Review on Day 10? Developers can be busy doing fixes, code documentation, refactoring, or helping test each other’s code to ensure everything is ready for the demo portion of the Sprint Review.
Day 10 – Review & Retrospective – Typically 1 hour for each ceremony. Remember that the Retrospective is reserved for team members only.
Day 2 – 10 Daily Scrum – Keep this ceremony short and sweet allowing just 15 minutes for the team to check in with each other. Answering the 3 questions, is to help them plan. It isn’t a status meeting.
For more on the ceremonies, go right to the source here http://www.scrumguides.org/
Calculating Sprint Capacity
I use this calendar to show the flow, plan for the meetings, and to identify my teams’ capacity for the sprint. How many hours does your team actually get to code in a sprint?
Typical Day – Considered to be 6 hours at most organizations based on an 8 hour day with 2 hours of email, admin and other meetings.
Days in a Sprint – 10 (if there aren’t any bank holidays or vacations) = 60 hrs per person, per sprint
Sprint Ceremony Allocation – Planning (4), Scrums (9 x .25), Review (1), Retrospective (1), Grooming (1) = 9.25 hrs per person, per sprint
Average Capacity per person = 50.75 hours (60 – 9.25 hrs)
This can be adjusted to suit your ceremony timings, and for holidays and vacations. (Hint: For a 3 day weekend reduce capacity by just 5.75 hours as everything else has already been deducted.)
Why is capacity important?
A team’s commitment may not be to last sprints velocity, if their capacity is reduced. It is good to understand the impact of holidays and vacations on velocity as a result of reduced capacity. Is this a surprise? Let me know. I’m always interested in your comments and feedback. Happy Planning!