Get certified - Transform your world of work today


Is ScrumMaster Time Tracked in Sprints?

6 May 2013

Hubert Smits - Agile Industry
Big Orange Square LLC

I recently was asked this question: "Typically, does the ScrumMaster have stories in any given sprint that track for iteration planning, backlog refinement, or any other sprint/Scrum tracking activities? Or does the ScrumMaster's time fall outside the velocity for the Scrum team?"

These are actually two questions, and there are some interesting assumptions within the topic. First, regarding ScrumMaster activities: Like other process and incidental activities, I do not write stories for them. Examples of these activities are holidays, support, training, and also Scrum process work such as sprint planning and daily Scrums. This includes such ScrumMaster activities as preparing for sprint planning. During sprint planning, each team member lists the time that is not available for development of new functionality (stories). The ScrumMaster will put some more hours in this bucket, probably twice as much as the average team member. An example of a capacity plan is in this picture.

(As an exercise to the reader, what can you say about this team's size?)

The remaining hours, in the "Capacity" column, are available for stories. When a team tasks out stories, and a team member commits to a task, the estimated hours for the task are subtracted from his or her capacity. Team members (this includes the ScrumMaster) can commit to tasks until their available hours reach zero. (All this is assuming that a team writes tasks, finds owners for tasks, and estimates tasks during the sprint planning).

So the short answer is: "No, do not write stories for ScrumMaster activities, nor for other Scrum team member activities, when those activities are Scrum process activities."

The issue of velocity is another question, and its answer follows from the above explanation. That is, only the size of accepted stories count toward velocity, and since a process activity is not a story, this work does not count toward velocity.

Finally, I'd like to make an observation, which is that the title of this article is "Is ScrumMaster Time Tracked in Sprints?" The easy answer to this question would have been that Scrum doesn't require time tracking, neither from team members nor from ScrumMasters. One method of progress tracking is the use of sprint burn-down charts, which work with estimated hours left to use, not with tracked hours.

Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.

Article Rating

Current rating: 4 (1 ratings)


Scott Friend, CSM,CSPO, 5/6/2013 5:22:57 PM
I am new to the community, so my lack of experience may be evident in the content of this comment. Hopefully if so, it can enlighten the discussions.

The last paragraph was the key. Time tracking is not an element of the scrum framework. Time tracking does not even apply to velocity, isn't velocity the number of estimated story points that were completed during a sprint - only through extrapolation of the team's hours can we roughly relate velocity to team-hours (which I think is a bad idea).

Arguably, a purely dedicated development team would not have members reserving time buckets for support. However the reality is that the team is likely responsible for some Tier 3 type support, and it needs to be removed from capacity. But, these time buckets should be constant for the team's. When a time bucket is under or over utilized, it will have a relationship to the number of tasks completed. This variation is not predictable, over time it should average out.

When talking about the Scrum Master's capacity planning, the Scrum Master is not a developer, therefore he or she should not be completing tasks that count toward the velocity of the development team. In the case that the Scrum Master is wearing multiple hats (which should not happen), then the Scrum Master's development capacity (and utilization) shall be considered.

The purpose of a velocity seems to be for release planning more than sprint planning. When planning a sprint, relative effort points (estimates) do not have any importance. The team should be breaking the features (or stories) down into the tasks, and estimating hours for each of the tasks. The team's capacity for the sprint will apply to making the sprint backlog commitment. This would mean that if a developer were to have a planned PTO day, this would reduce the team-hour capacity.

So, the way I see this is that if the capacity of a team is altered for a sprint, the velocity of that sprint will likely be effected (like running a 12 cylinder car with one cylinder missing will reduce the overall performance). It is a temporary situation for the single sprint. Again, over time it should normalize.

I wonder what others think.
Shane Poole, CSP,CSM, 7/5/2013 4:35:58 AM
The simple and quick answer is no.
The team work on the tasks which they created as part of Sprint Planning which help them to deliver the User Stories that they have committed to. The ScrumMaster’s role is to remove any impediments (blockers) that are holding this progress up. The important thing is to track the team not an individual and certainly not the SrumMaster.
I personally see an advantage in tracking both User Story points (bar chart) and Hours (line chart) in the Sprint Burndown as it gives the whole team two perspectives on progress.
Mary Ann Rayla, CSM, 7/10/2013 2:30:20 AM
I agree with Shane. The Scrum Master is only responsible over the scrum process and don't have any involvement in any of the sprint tasks.However, the Scrum Master may suggest on how many points or hours to put on a certain tasks base on experience,effort,complexity, but still the decision is not the Scrum Master's to make, the final words should come from the scrum team.
Bhushan Kulkarni, CSM,CSD, 7/22/2013 3:55:03 AM
I agree with Shane.
Jon Jorgensen, CTC,CSP,CSM,CSPO, 5/26/2014 4:25:04 PM
I'm not sure that there is a hard and fast "right way" to approach capacity calculation, related to subtracting individual's PTO hours from said capacity, or completing the task breakdown, and pre-assigning each task out to individual team members. Were that approach taken, the team must then answer the question, "Do we push this User Story out of our sprint planning, and back into the Product Backlog because 1 of our 12 people [that's the scenario described] can't fit it into their capacity for whatever reason?" That's a lot of constraints to manage. (Forget about the 144 communication paths for a moment!)

Other people approach Sprint Planning in 1 stages: The "WHAT" meeting and the "HOW" meeting. Generally, in this paradigm, historical velocity is simply assumed as an accurate, but imprecise indicator of current capacity. The Product Owner pulls off the top of the Product Backlog, whatever number of user stories both A) pass the INVEST test and B) fit the new sprint's capacity and ideally, represent some kind of sprint theme (maybe a Minimally Viable Feature).

After that meeting is over, and generally the Product Owner has gone back to manage expectations across the stakeholders, etc. (fulfill their role) then the Scrum Team and maybe the ScrumMaster get together to figure out the "HOW" to deliver the sprint theme. And that's when the tasks come out. Uh-oh! What if there are more hours in tasks than the sprint? Shouldn't be a problem if the team is working on the highest value story first, and sequentially descending from there, right? If you didn't finish a user story or 2 by the end of the sprint, maybe the Product Owner decides they don't want them because they're too expensive, or they get resized, and pulled in the next sprint. There are lot's of happy endings other than precise planning meant that we couldn't pull it in the sprint, even with 12 people. Does this make any sense to anyone? This is how I've been trained, and have lived Scrum for years now. It seems to me, to be fairly 'harmless.'

You must Login or Signup to comment.

The community welcomes feedback that is constructive and supportive, in the spirit of better understanding and implementation of Scrum.


Newsletter Sign-Up