Scrum takes a considerably different approach to determining a team member’s capacity. First of all, Scrum assigns work to an entire team, not an individual. Philosophically, this places an emphasis on collective effort. Second, Scrum teams prefer not to quantify work in terms of time because this would undermine the self-organization central to the success of Scrum. This is a major break from waterfall: Instead of a manager estimating time on behalf of other individuals and assigning tasks based on conjecture, team members in Scrum use effort and degree of difficulty to estimate their own work.


What does the process of estimation look like? Scrum does not prescribe a single way for teams to estimate their work. However, it does ask that teams not estimate in terms of time, but, instead, use a more abstracted metric to quantify effort. Common estimating methods include numeric sizing (1 through 10), t-shirt sizes (XS, S, M, L, XL, XXL, XXXL), the Fibonacci sequence (1, 2, 3, 5, 8, 13, 21, 34, etc.), and even dog breeds, in which a Chihuahua would represent the smallest stories and a Great Dane the largest. The important thing is that the team shares an understanding of the scale it is uses, so that every member of the team is comfortable with the scale’s values.

In the Sprint Planning Meeting, the team sits down to estimate its effort for the stories in the backlog. TheProduct Owner needs these estimates, so that he or she is empowered to effectively prioritize items in thebacklog and, as a result, forecast releases based on velocity. This means the Product Owner needs an honest appraisal of how difficult work will be. Even when the team estimates amongst itself, actions should be taken to reduce influencing how a team estimates. As such, it is recommended that all team members disclose their estimates simultaneously. Because individuals “show their hands” at once, this process is not unlike a game of poker. Unsurprisingly, teams often call estimation “planning poker.” Some teams have even developed their own decks of playing cards expressly for this process.


Still, even when teams possess a shared understanding of their scale, they can’t help but estimate differently. To arrive at a single effort estimation that reflects the entire team’s sense of a story’s difficulty, it often requires numerous rounds of estimation. Veteran teams who are familiar with the process, however, should reach a consensus after just a few rounds of planning poker.


In Scrum, every iteration begins with the sprint planning meeting. At this meeting, the Product Owner and the team negotiate which stories a team will tackle that sprint. Time-boxed to four hours, this meeting is a conversationbetween the Product Owner and the team. That is, it’s up to the Product Owner to decide which stories are of the highest priority to the release and which will generate the highest business value, but the team has the power to push back and voice concerns or impediments. This is a good thing since the team may be aware of a legitimate impediment keeping the team from moving forward.


When the team agrees to tackle the work, the Product Owner adds the corresponding stories into the sprint backlog. If a team uses manual agile, this might be physically represented by moving a Post-It note or index card with a story written on it from the backlog into the sprint backlog. If a team uses an agile tooling solution, this might be represented in a number of ways. A tool my company uses, ScrumWorks® Pro, has a two-paned view of a project, in which the product backlog appears on the right and the sprint backlog on the left. Using an intuitive, drag-and-drop interface, the Product Owner can easily add stories to the sprint.


At this point, the Product Owner is typically asked to leave while the team decomposes the sprint backlog items into tasks. While the Product Owner is asked to leave so that the team can candidly discuss the work, he or she is still expected to be “on call” to answer questions, clarify acceptance criteria, or renegotiate. This meeting, which was previously called the sprint definition meeting, is also time-boxed to four hours to limit all sprint planning activities to a single day’s time.