Archive for November 2009

A Brief Defense of Time: Estimating Sizes for Scrum Projects

November 12, 2009

Not long ago, I participated in a discussion about effort estimation in Scrum. The basic point is simple: In order to plan a Sprint, we need to have reasonable estimates for how much work the team can do in the Sprint (its “velocity”), and how much work is needed to implement each Story under consideration.

The discussion revealed a major split between two approaches for estimating effort and velocity. While both defined a sizing unit named “point,” the definitions were quite different.

Points as a Measure of Effort

“Effort” refers to an amount of work. The units of effort are time-based, such as “person-hours” or “person-days,” and describe the time spent on a specific task by a person.

Effort differs from duration in that a single person-day of effort may be spread across two or more calendar days, if the person only devotes part of each work day to the task. The ratio between the effort someone spends on a task, and the duration of the task, is his availability. Even someone who is officially dedicated to a particular task full time will have some of his day taken up by overhead, such as meetings, phone calls, and email. (A reasonable rule of thumb for the availability of someone dedicated full-time to a task is 75%, meaning he is likely to spend about six of his eight work-day hours on the task.)

When points are taken as a measure of effort, the usual definition is that one point equals eight person-hours, or one perfect person-day. Team members then estimate a Story’s size based on how much effort they believe the Team will expend to implement the Story.

The Team’s velocity is the number of points of effort available for the Sprint, based on the members’ availability and the number of workdays in the Sprint. Given the velocity and point estimates for Stories, it is easy to determine how many of the top candidate Stories will fit into the Sprint.

Points as a Measure of Complexity

It seems obvious that the complexity of a Story affects the effort required to implement the Story, so complexity makes sense as a sizing metric. Unfortunately, there is no standard means to define complexity for a Story. (Function-Point and related techniques might provide such a standard, but are not commonly used in Scrum projects.) Instead, various estimation techniques are used to create a relative numerical scale, such that a Story with a larger point estimate is more complex than one with a lower point estimate.

Estimation techniques often analogize Story complexity to common physical tasks, such as “moving piles of dirt” or “painting the house,” or to commonplace scales such as “T-shirt sizes.” Historical information is very important, so that a Team can say, “This Story is about as big as that three-point Story X from last Sprint, so we should estimate it at three points.”

Team velocity is then not computed a priori from team size, but based on historical data regarding how many points the Team implemented in the last Sprint. Again, once Story sizing and Team velocity are known, it is easy to determine how many of the top candidate Stories will fit into the Sprint.

Which is Better?

We can’t answer the question unless we know what “better” means. Possible measures of “better” include

  1. Reliability of predictions about the Team’s ability to complete a planned set of Stories per Sprint
  2. Ease with which Team members understand and internalize the scale
  3. Ability to measure increases in productivity over time
  4. Support for Scalability, by ensuring uniformity of definitions across Teams
  5. Transparency and comprehensibility to external stakeholders
  6. Opacity and insulation from interference by external stakeholders

The first measure should be the most important, since it is the reason for having an estimation process. The other measures are secondary (and 5 and 6 are diametrically opposed).

So which approach is better, given these measures?

I believe that Effort estimates do better for measures 2, 4, and 5, while Complexity estimates do better for measures 3 and 6. I have seen no compelling evidence that either approach is superior for the key measure, #1. In other words,

It doesn’t matter whether you choose Effort or Complexity estimates for Story sizing and Sprint planning. They both work.

Heated debate between comparable alternatives usually reflects strongly-held values. If one were clearly superior, there would be no need for debate. If neither were superior, and strongly-held values were not an issue, no one would care enough to engage in debate. The fact that such a debate exists tells me that such values have come to the fore, and I find this interesting.

What are these values? I can’t speak for everyone, but here are my guesses:

Effort estimation appeals to those who prefer metrics that can be measured against an objective standard, such as time. These people

  • Value scalability, and so prefer metrics that are uniform across teams
  • Have a good relationship with external stakeholders, and want to provide the latter with useful status information that is easy to understand
  • Like to create mathematical models, and find them useful

Complexity estimation appeals to those who prefer metrics that cannot be measured against an objective standard. These people

  • Do not want anything that smells of the ‘bad old days’ of waterfall projects, such as time-based metrics, because the latter open the door to criticism when performance differs from estimates
  • Do not trust external stakeholders, and wish to keep status information private within the Team, and unintelligible to outsiders, because outsiders may try to meddle if they know what is happening within the Team
  • Dislike mathematical models, and do not trust them


I don’t believe that the above reasons provide the whole story for why some people prefer one sizing metric over the other. I’m sure that personal feelings about what feels most natural play a role, and I’m also sure that those who started with a particular approach and found it successful see no reason to change.

However, I’ve seen enough insularity (‘Scrum islands’) and distrust between development teams and business stakeholders to find these plausible influences for shaping metrics. I’ve also seen strong knee-jerk reactions among Scrum experts against anything that they associate with failed waterfall-style projects. I think the latter is a mistake, and leads to throwing out the baby with the bath-water, but it is definitely an influence.

So at least in some cases, I suspect that a preference for subjective measures of Story sizing and velocity is driven partly by distrust and an ‘us versus them’ attitude. If so, I think it would be wise to build bridges and improve trust, rather than accept the status quo.


When Scrum is too Much

November 2, 2009

Scrum was designed as a lightweight process framework for software development, with the intent to impose a minimal amount of overhead and structure. So it is interesting to consider cases when Scrum is itself too “heavyweight” for a project, and something lighter is more appropriate.

The “Sweet Spot” for Scrum

Scrum is optimized for projects that have high uncertainty (due to the inability to estimate effort accurately), a high likelihood of frequent changes of direction (due to rapidly-changing requirements), and the need to respond quickly to customer requests. For these reasons, it mandates short development cycles of uniform length, to minimize risk and maximize responsiveness to rapidly-changing customer needs. The emphasis on short cycles enables a predictable schedule of releases, each of which is the result of one or more development cycles.

The “Sour Spot” for Scrum

Let’s think about some examples of projects for which Scrum is not particularly useful.

I don’t use Scrum to make a cheese sandwich. I use a waterfall process, following a template devised long ago: I get out two pieces of bread, slice enough cheese for the filling, and assemble the sandwich.

I also don’t use Scrum to build a set piece for a play. Instead, I collaborate with as many other volunteers as we can reasonably use, and work on the piece until we have to quit for the day, or until it is done. After one or more work sessions, we finish the piece and move on to the next. This process is neither Scrum nor waterfall in nature, but bears more of a (rather vague) resemblance to Kanban.

So what do these examples tell us? Basically, they say that Scrum is much less useful when the work is thoroughly understood in advance, or when the delivery date is not specified, and not cyclic.

A Real-World Example: LifeHints

I’ve been helping out some friends at LifeHints over the last year, working with them to set up development guidelines. My first thought, of course, was that the LifeHints folks should use a Scrum process, but I soon changed my mind.

Why not use Scrum? Well, before their first release, they had no established customers, and so no customer requests, for features or release schedules. Thus the cyclic nature of Scrum provided no particular benefits, and responsiveness to customers was not an issue.

What was in issue was the need to build a system incrementally, starting with the simplest scenario (logging in and showing a home page), and adding functionality bit by bit over time until the application had enough to be useful. This process definitely required agility, as the requirements evolved in unpredictable ways over time. It also required daily, or near-daily, builds that worked, so that everyone could see how the new features were shaking out.

In a nutshell, the LifeHints team, which contained both Product Owner and Team member roles, worked in short but variable-length iterations, refining requirements and refactoring code as needed, until the evolving vision and the evolving product converged to a useful reality.

This process was very effective, and I suspect it occurs frequently in pre-release startup companies. I also suspect that, as the company and its customer-base grow, something more formal will eventually be required, and Scrum will become an attractive option.


Everyone knows the saying, “When your only tool is a hammer, every problem looks like a nail.” Scrum is a tool in the toolbox of project management, and, like any tool, is better-suited for some situations than others. For the people at LifeHints, Scrum was too structured and prescriptive for the company’s stage of development. Given the focus on Scrum as a lightweight framework, I find the irony gently amusing.

(For the curious: LifeHints provides guidance on what things you need to do to live a life that reflects your personal preferences. You can check it out at