content top

Scrum at Scale Part II

Scrum at Scale Part II

Scrum Inc.’s Alex Brown and Jeff Sutherland present Scrum at Scale Part II – an object-oriented model for scaling Scrum across the business. The modular approach allows for the overall system to work together even if individual modules aren’t agile. This allows the framework to support many different contexts verses other more “tightly coupled” scaling systems.

This one-hour course re-caps the framework and dives into how to manage cross-team dependencies. 

This is part 2 of 2 in our Scrum at Scale series. You can view Part I here

 Scrum Inc.’s online courses are eligible for Scrum Alliance SEUs and PMI PDUs. See FAQ for details.

 Scrum-EntInfographic-FINAL7-crop

A pattern is a practice or process that has been observed to address a specific set of challenges in a defined context. Patterns have emerged because scrum is proscriptive about the goals of each part of the framework but says very little about how to meet those goals. As such, over the years common practices have emerged to help teams meet those goals in the face of known impediments. Much like a play out of a sports team’s playbook, patterns help teams react to change and set the stage for success.

Click here for scaling patterns and to submit yours

Back to All Topics


Read More

Definition of Done

Definition of Done

Each Scrum Team has its own Definition of Done. What matters is that each Team has a shared definition that every one understands. The Team’s Definition of Done is used to assess when work on a User Story has been completed.

Here’s one example: “Done means coded to standards, reviewed, implemented with unit Test-Driven Development (TDD), tested with 100 percent test automation, integrated and documented.”

The Definition of Done ensures everyone on the Team knows exactly what is expected of everything the Team delivers. It ensures transparency and quality fit for the purpose of the product and organization. As Jeff points out in video, getting stories done can double a Teams Velocity. The slides delineate how to get stories both Ready and Done.

Back to All Topics


Read More

Scrum at Scale Part I

Scrum at Scale Part I

Scrum Inc.’s Alex Brown and Jeff Sutherland present Scrum at Scale Part I – an object-oriented model for scaling Scrum across the business. The modular approach allows for the overall system to work together even if individual modules aren’t agile. This allows the framework to support many different contexts verses other more “tightly coupled” scaling systems.

This one-hour course covers:

    • the full case for a modular vs. deterministic model of scaled Scrum
    • the overall vision for a modular scaled Scrum that spans the team, program/product/business unit, and enterprise levels
    • specific examples of different successful practices

You will not leave this course with a cookie-cutter answer for large-scale Scrum implementations. Instead, it will fundamentally change the way you think about agile processes within your organization and equip you to lead a thoughtful exploration of what the organization really needs from scaling Scrum.

This is part 1 of 2 in our Scrum at Scale series. 

 Scrum Inc.’s online courses are eligible for Scrum Alliance SEUs and PMI PDUs. See FAQ for details.

 Scrum-EntInfographic-FINAL7-crop

A pattern is a practice or process that has been observed to address a specific set of challenges in a defined context. Patterns have emerged because scrum is proscriptive about the goals of each part of the framework but says very little about how to meet those goals. As such, over the years common practices have emerged to help teams meet those goals in the face of known impediments. Much like a play out of a sports team’s playbook, patterns help teams react to change and set the stage for success.

Click here for scaling patterns and to submit yours

Back to All Topics


Read More

Points vs Hours

Points vs Hours

Estimation is a fundamental building block in Scrum. Without it Product Owners and Scrum Masters will struggle with securing a release date and showing velocity improvement. When adopting Scrum the tendency is to continue approximating in time. Unfortunately, reams of research shows that humans are inherently horrible at estimating in time. It turns out when we estimate jobs by how long they will take us to complete we have an error rate of 400%. 

So, how should we estimate? If we use relative sizing (small, medium, large,) our error rate drops to a more reasonable 50%.  This is why Scrum Inc.’s recommends to estimate the amount of effort it takes get a job done in points. Story points give more exact estimates, drastically reduce planning time and more accurately predict release dates. And, without points, calculating Velocity is impossible. Without Velocity, there is no way for a Team to inspect and adapt and continuously improve, which is the essence of Scrum. 

If your Team is still estimating in hours, stop and watch the online course below.

 Scrum Inc.’s online courses are eligible for Scrum Alliance SEUs and PMI PDUs. See FAQ for details.

Traditional estimation results in what is quite brilliantly termed “The Cone of Uncertainty.”  The graph shows that beginning estimates of work can range from 400 percent beyond the time actually taken to 25 percent of the time taken. The low and high estimates

Cone of Uncertaintydiffer by a factor of sixteen. As the project progresses and more and more gets settled, the estimates fall more and more into line with reality until there are no more estimates, only reality.

It is often framed as a debate of Points vs Hours, but in reality there is no debate. Estimating in Points is still estimation, an educated guess, but it gives far more accurate, predictable, and stable estimates. Estimating in hours will simply result in estimates that are so far off the mark as to be useless. There are reasons why traditional software projects so often come in late and over-budget. The insistence on estimating in hours instead of Points is a major factor.

 

Reason 1: Humans are Bad at Estimating in Hours

Humans have been able to measure time for millennia but until about 150 years ago (when clocks became more accurate and widely available) measuring time in anything more precise than days was all but unheard of. Essentially, humanity has evolved over hundreds of thousands of years not using hours and, as a result, is bad at estimating in them.

What humans are good at is estimating relative size. Research backs this up. At the outset of the Cold War, the Department of Defense, asked the RAND Corporation to forecast how modern technology would change warfare. (How long will it take for a country to develop a nuclear weapon?) RAND discovered that time-based estimates had large error rates and wide variability, and that humans were much better at estimating relative sizes, particularly those that follow the Fibonacci sequence. (The sequence is effective in estimation because the sum of the quantities of the larger number is equal to the ratio of the larger number to the smaller one. And, as the video to the left so aptly demonstrates, it is a pattern the human race has seen everywhere in the natural world since the beginning of time.)

A recent Microsoft study analyzing two Scrum teams (one estimating in hours, the other in points) showed similar results. The Team estimating in Points had an error rate of +/- 25%, whereas the team estimating in hours had an error rate as large as +/- 400% (denoted as the light grey line in the slide to your right.)

Another advantage of estimating relative size is that it is faster than trying to plan how many hours it will take to complete a job.

Reason 2: Using Hours Undermines Velocity

In Scrum, Velocity is used both to quickly project how much effort it takes to complete a job and as a metric to determine how a change in process effects productivity. (If output goes up, keep the process change, if not revert to the previous process.) If a Team measures in hours, it will be impossible to gauge output or measure productivity.

This is because hours measures input and Scrum is based on measuring output. For example, if it takes one team member an hour to complete a job and another team member two hours to complete the same job, the output (the job being completed) is the same despite the different amount of time put into the job. Estimation of output needs to be the same regardless of who is doing the work. Velocity measures the collective effort of the Team and not the input of an individual team member.

Reason 3: Time is Finite

There are only 40 hours in a typical workweek. If effort is measured in hours, a 5 member Team can never exceed 200 hours of work in a week. Hyper-Productive Scrum Teams increase output by 400% or more. In order to realize these gains when measuring in hours, every team member would have a 160-hour workweek. Not possible and definitely not a Sustainable Pace.

Improvement comes when the overall team becomes more efficient through improving both process and practices. If it once took a team member two hours to complete a job but now she can do it in one, her output has doubled but the time she put into the job has reduced by half. Measuring in hours would never capture her improvement.

As long as it is conceptually tied to time, Velocity will have no value.

Often, organizations are resistant to using points because management is concerned about Teams artificially inflating the amount of points it takes to get a job done. Why not just estimate a job at five points of effort rather than the three that it is actually worth, creating two points of inflation and artificially increasing Velocity?

Regardless of the validity of this concern, Teams are more likely to deflate point value.

For example, the team member who can now complete her job in one hour instead of two might be inclined to estimate that same job at a lower point value in a future Sprint Planning meeting because she feels like it takes her less effort now that she has improved productivity. This is point deflation. Her output is the same so the job should be estimated at the same point value.

However, both inflation and deflation can be measured and controlled using Scrum Management Metrics.

(Hours also suffer from inflationary pressures because they are often used to compare employee effort. Using a technique called Value Stream Mapping shows that few companies achieve process efficiency above 15% without focused effort. No employee wants to admit that out of a 40 hour work week they only accomplished 6 hours of actual work.)

Patterns:

 

Points

 

The Scrum Pattern Language of Programing : The PLoP movement codifies well know Agile practices that have been successfully implemented many times.

Back to All Topics


Read More
content top