How Many Days of Productivity in a Sprint?

Question that prompted this article:  “Some of our teams have begun deducting the time spent in the Daily Scrum from their Sprint Capacity.  While I can’t pinpoint anything wrong with this, my gut is telling me something’s not right.  What do you think?”
 
Disclaimer:  this article is assuming that we are not using Agile Estimating and Planning methods, and that our estimates and team capacity calculations are based on hours and not story points.

As part of Sprint Planning we expect the team to assess their capacity for the coming Sprint.  They should account for any “non-productive” time, such as holidays, corporate meetings, support, etc., and deduct that from their baseline starting point of available hours.  Should they consider the Scrum meetings as “non-productive” time and deduct that also?

Let’s go through each of the Scrum meetings and decide.

Sprint Planning:  this is the time we use to plan out the work that’s ahead of us in the coming Sprint.  We may indeed be taking care of some design work while we’re in this meeting, but it’s hard to argue that this time can be counted in our capacity because we don’t know what we’ll be working on until we get through the detail of this meeting.  The consumption of our capacity begins when this meeting ends, so I’d argue that we must deduct time spent in Sprint Planning from our entire Sprint capacity.  Please note that this does not mean our time spent in Sprint Planning is “non productive.”  Quite the opposite!  We can’t however, include that time spent in Sprint Planning in the coming days of the Sprint.

Daily Scrum:  this is the time we use to check in with each other and to provide status to observers.  We’re in the middle of working on producing the product of the Sprint while we’re in these meetings.  The three questions used in this meeting contribute directly to that day’s productivity.  Because of this I have a difficult time looking at these meetings as not contributing to the work effort.  I ask teams to leave their capacity alone when it comes to accounting for the Daily Scrums.  (Side note:  if a team argues that they have every right and need to deduct the time spent in the Daily Scrum, I’d begin to question the team’s interest in tracking time.  If they begin nit-picking about this, there may be another issue that needs to be investigated.).

Sprint Demo/Review:  this is the time we use to demonstrate to our Product Owner and other interested stakeholders the work product that was attempted during the previous Sprint.  We also reserve some time to review what went well and what could have gone better.  At this point our work for the Sprint is done, so there’s no opportunity to further contribute to that product in this Sprint.  Because of this I would allow the team to deduct from their capacity the preparation time and actual meeting time for the Sprint Demo.

Retrospective:  this is the time we use for the team’s sake to allow for self-inspection.  “How are we doing as a team?” is the spirit of investigation during the Retrospective.  Different teams hold Retrospectives at different times, and in some cases the team may work for more than one Sprint without having a Retrospective.  While the Retrospective can indeed focus on the events of a particular Sprint, the goal of this meeting is not necessarily tied to a Sprint, but instead could be about team behaviors, tools, interactions, etc., that rise above any particular Sprint.  Because of this I would allow the team to deduct the time spent in the Retrospective from their capacity calculation.

While your own experience may dictate other conclusions, in summary, we have the Sprint Planning Meeting which cannot be included in capacity, the Daily Scrum which should not get deducted from capacity, and the Sprint Demo/Review and Retrospective which can be deducted from capacity.  This information is important for two reasons.  First, it allows us to plan properly in Sprint Planning.  Second, it allows us to project team capacity at the project level.  For example, if we are asked to assess how many Sprints it would take our team to complete a particular project that has already been estimated, we need to use a capacity number that fairly represents what the team can actually do in a Sprint.  It would be a terrible mistake if the team did not deduct one day from their Sprint capacity to account for Sprint Planning, for example.

What about our interest in promoting self-management?  Why should I dictate what they can and can’t deduct from their capacity?  As with many of the items we explore in these writings, common sense must still prevail.  We need to provide guidance to our teams, and there will be some need to consistency across teams.  Make your own informed decisions based on your situations,and keep with the spirit of Scrum!

From classroom training (ranging from 2-hour overview sessions to 2-day Certification Training) to organizational consulting, we can help with all your IT project needs. If you would like to learn more, call us at 954-575-8766, or email us at info@winnowmanagement.com

You linked to Scrum Notes from the Home page.