Scrum Methodology

Scrum Effort Estimation and Story Points

Posted by admin under Scrum Basics

In waterfall, managers determine a team member’s workload capacity in terms of time. That is, managers estimate how long they anticipate certain tasks will take and then assign work based on that team member’s total available time. This is problematic because it does not distinguish between a story that is very hard to complete and one that is undemanding; it only considers how long the work will take. To put it another way, coding a feature and organizing the heaps of documentation on your desk are activities that likely take the same amount of time, but there’s no question that the former would require much more sustained concentration and effort. Because of that fact, they should be recognized as incredibly different tasks, requiring different levels of effort.

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 refuses 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. The Product Owner needs these estimates, so that he or she is empowered to effectively prioritize items in the backlog and, as a result, forecast releases based on velocity. This means the Product Owner needs an honest appraisal of how difficult work will be. Thus it is recommended that the Product Owner does not observe the estimation process to avoid pressuring (intentionally or otherwise) a team to reduce its effort estimates and take on more work. 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.

Need an example? Watch an example team conduct a Backlog Grooming Meeting, including relative estimation and example user stories. Planning poker is demonstrated at the 4 minute mark of this video:

 
To see how velocity is computed from story points, watch an example Sprint Review Meeting including velocity measurement.
 

Tags: scrum effort estimation, scrum playing cards, scrum poker, scrum story points

Scrum Acceptance Criteria

Posted by admin under Scrum Basics

In Scrum, a Product Owner would never deem a team’s work “done/done/done” until he or she had consulted the story’s acceptance criteria. Acceptance criteria are the requirements that have to be met for a story to be assessed as complete. Acceptance criteria are incredibly important in Scrum because they spell out what a Product Owner expects and what a team needs to accomplish. There are no hairs to split and no points to argue. If it’s in the acceptance criteria, then it needs to be in the release.

So what happens when only some—most, even—of a story’s acceptance criteria is met? Should the team be awarded a corresponding percentage of the story points? Well, no. Scrum frowns on partial credit for work that is only partially completed. All of the criteria must be fulfilled or else the work is incomplete. (Many ScrumMasters won’t allow teams to present work that hasn’t been completed.)

Why does Scrum only accept work that is 100 percent complete? First of all, an implicit acceptance criterion of any story is that it must be completed during the sprint it was assigned. Work is confined to the sprint, so a team must complete the work in that sprint as well. Second, it’s common for teams to discover the final one percent of work to be more challenging than they expected. It might sound like a Yogi Berra-ism, but if it’s not done, it’s not done. Third, when a Product Owner awards unearned credit, it results in velocity inflation, rendering the team’s velocity an unreliable metric for forecasting. Furthermore, when a team is awarded credit for a story that it will have to finish in the next sprint, it means the team’s workload is even greater than the sprint backlog suggests. When this happens, a team has to play catch up, which often leads to a team falling behind and accruing substantial technical debt along the way.

Clearly, it is in the interest of the team to only award credit when it is completely earned. Partial credit only serves to undermine a Product Owner’s ability to forecast accurately and risks building technical debt.

Tags: Acceptance Criteria

Agile Conference 2008

Posted by admin under Agile and Scrum

Here’s an interesting video I reposted from the Agile Journal website: an interview at the Agile 2008 conference in Toronto between Agile Journal reporter Patrick Egan and Victor Szalvay, co-founder of Danube Technologies, Inc. and Product Owner for the ScrumWorks Pro agile management tool. It only clocks in at about five minutes, but, in that time, Patrick and Victor cover a lot of ground. Topics discussed include agile adoption trends; the evolution of agile tooling solutions; common challenges organizations face when adopting agile; and how Danube uses Scrum to manage all their projects, from budget forecasting to marketing.

Tags: Agile Conference 2008