To Estimate or Not, that is the Question?By David Bulkin

One popular debate today is whether estimating is worth the effort. To those experienced with Scrum, this question seems silly, how can you prioritize the Product Backlog, or identify what can fit in a Sprint, without an estimate? Aren't you just rolling the dice if you don't estimate?

This is actually a misunderstanding. If you apply kanban without fixed iterations, the focus is not on how big an effort is, but when it will be complete. As such, instead of estimating size, kanban estimates cycle time, which, in the end, is still an estimate.

The common example given is joining a line. Do you care how long (i.e. big) the line is, or do you care how long you will have to wait (i.e. the cycle time)?

The Corey Ladas Take

Corey Ladas explains the latter view in a posting on his blog, a portion of which is quoted below. I added the boldface to the last sentence:

"Rather than go through the trouble of estimating a scope of work for every iteration, just make the backlog a fixed size that will occasionally run to zero before the planning interval ends. That’s a simple calculation. It’s just the average number of things released per iteration, which in turn is just a multiple of average cycle time. So if you have 5 things in process, on average, and it takes 5 days to complete something, on average, then you’ll finish 1 thing per day, on average. If your iteration interval is two work weeks, or 10 work days, then the iteration backlog should be 10. You can add one or two for padding if you worry about running out. This might be a point that’s been lost on the Scrum community: it’s never necessary to estimate the particular sizes of things in the backlog. It’s only necessary to estimate the average size of things in the backlog."

Now, since I took the quote out of context, you may want to read his entire blog posting, or attend his upcoming class on June 11th in Atlanta, to find out more.

The Cases for and Against Estimating

Many reasons are cited against creating estimates; just a few are listed:

• The estimates are never accurate, so they don’t add value.
• Even if the estimates are relatively accurate, we know we have to do the work, so why waste the time.
• The process of creating an estimate creates resentment when everyone is forced to chime in, and reach consensus, even when they don’t agree.
• The estimate itself causes people to modify their behavior in destructive ways, typically pressuring them to finish, causing low quality. In those instances where they are ahead, the estimate causes them to relax and waste time.

There are also many reasons cited for creating estimates, once again, just a few are listed:

• Determining business value depends upon an understanding of both return and cost, so you can’t determine value unless you estimate effort.
• You can’t plan a Sprint without estimates, or, if you are doing waterfall, you can’t build your schedule without estimates.
• Without estimates the team will lack discipline and will waste large blocks of time, potentially overbuilding a simple feature.

Simple Scenarios

As with most questions in respect to process, the answer is, “it depends”. But, here are some extreme examples to guide the decision on whether or not to estimate.

If you are fixing bugs in a mission critical system, and these bugs are prioritized by severity, and all high severity bugs must be fixed, then it is clear that estimating adds little value. Simply work on the highest priority bugs, and get the fixes released as quickly as possible.

On the other hand, if you are working on new development, or adding a large new feature set, and you must present a complete business case, including expected return and cost, then you will need to create some form of estimates.

Guidance for the Rest of Us

If you are somewhere in the middle of these two extremes, you need further help in deciding how to proceed.

• Remember the difference between size and effort. When you are estimating features, you are estimating size, so use a relative point scale and let the velocity calculation convert size to time. When you are estimating tasks, use an absolute measure like hours/days to represent the time required to complete a task.

• Create your estimates quickly and don’t get paralyzed by precision. Being quick may be the middle ground between estimating and not estimating.

• If you don’t have enough confidence to estimate, don't! Either execute a research spike to find out more, or simply delay creating an estimate until work on related stories or tasks give you an increased level of confidence.

• If technical uncertainty is high, and you must proceed now, allocate instead of estimate. With an allocation the business can limit the maximum effort and the team can monitor real world progress to cut short efforts that won't be finished in the time allocated.
  

• Use either a simple estimation scale, like T-Shirt sizes (S, M, L, XL), or a more complex scale that has increasingly larger gaps. Doubles (2, 4, 8, 16, 32) and fibonacci sequences (1, 2, 3, 5, 8, 13, 21) are both examples of scales with increasingly larger gaps that demonstrate that uncertainly increases along with size.

• Adjust estimates based on actual experience. The counterpoint to this is to bury your head in the sand.

• Involve the Product Owner and the business at large.
  
  
  • Although it should go without saying, the Product Owner should be deeply involved in the estimation process, providing insight and guidance.
  • The Product Owner should also be involved in the daily stand up meetings where progress is discussed so that he/she can gain an appreciation for the uncertainty inherent in the estimation process.
  • The Product Owner and the ScrumMaster should continually remind the business community at large about the limitations inherent in the estimation process.
  
  
• Most importantly, focus on the journey, not the destination. Sounds abstract, but instead of worrying about the exact estimate (is it 5 Story Points or 8), focus on why people vary on their opinions so that you can better understand the story and the work that will need to be done to deliver it. If you engage the whole team in the estimation process the context gained from can be more valuable than the estimate itself.

In Closing

I estimate that at least 10% of the people reading this post would find it useful, so please send an email or comment on the post so I can see how accurate my estimate was.

COBOL Maintenance, A Model for Modern Agile Processes?

At the Lean/KanBan Conference on Thursday 5/7, Eric Willeke of Inkubook gave a unique, purely visual, well received presentation about Inkubook’s journey to Kanban. They eventually progressed to a mature Kanban approach, with a visual board, strict Work-In-Process (WIP) limits, and short lead times. As a result of a massive layoff, the business analysts were let go and the company size was cut in half. On the positive side his team started to communicate directly with marketing and the now much smaller team was able to swarm, and instinctively keep WIP low, without using the physical Kanban board or setting explicit WIP limits. His talk reminded me of high performing teams of old (I presented on just this topic at the March 3rd Agile Philly Meeting), as such, this blog is about those teams and what we can extrapolate from their experience.

Historical Perspective

In my 25 year professional career, I have seen software teams that have performed at exceptionally high levels by following what I will call a continuous flow approach. For the sake of this blog posting, continuous flow software development can be defined as a software development model where highly collaborative teams work on a small number of tasks at a time, often swarming, to take work from inception to production in very short time frames.

What might be surprising to some, is that some COBOL maintenance teams were early practitioners of this modern approach, many of these teams date back to at least the early 80’s (probably earlier, but I have not personally seen or read about them).

Maintenance teams often had to understand the interaction of thousands of lines of code, just to fix a single bug, and they were frequently under pressure supporting mission critical systems. As such, the best developers were often assigned to maintenance, not to new development!

Typically, team members had many years experience working in one industry, and often for one company. As such they acquired an in depth understanding of the business they supported. They also built close relationships with business peers, meeting on an almost daily basis, often sharing lunch, and frequently meeting outside of work. In short, they were anything but isolationist computer geeks. Since the COBOL language, and the mainframe environments on which they ran, evolved slowly, the programmers were experts with the tools they used, and their many years in the industry allowed them to be experts in the domains and systems they supported.

These teams were small, and they were able to deliver into production with the only requirement being sign-off from their business peers that the system was ready. The team members could do business analysis, design, and systems testing, along with coding, while following a highly agile, continuous flow process. The team members seldom worked in isolation, they pulled in bugs to fix based on input from the business, and they often swarmed on a single bug to quickly complete it.

Practical Applications

From a practical perspective, the historical perspective on high performing teams gives insight that is still valuable today.

It further emphasizes the power of the generalizing specialist concept. A generalizing specialist is a term coined by Scott Ambler, to represent individuals who are a good at many things and a master of a few (as contrasted to a generalist who is not a master of anything). I don't discount the value of specialist, but having some generalizing specialist on the team can result in significant improvements in productivity by providing flexibility on task assignments and simplifying communications (i.e. multiple team members can speak each others language).

Along a similar vane, it demonstrates that swarming is an effective approach. In general swarming helps improve short term effectiveness by leveraging the skills of specialists and decreasing WIP, and it increases longer term effectiveness by increasing knowledge transfer. This knowledge transfer can over time, result in the generalizing specialist as defined above.

Finally, it provides further clarification that keeping WIP to a minimum, pulling work when the team is ready (instead of having it pushed) and emphasizing fast turn around is a natural and effective way to develop software.

WIP limits are core to Kanban, but they also apply to Scrum. In fact, a story point limit on a Sprint Backlog is a form of a WIP limit on what enters a Sprint. You can go one step further with WIP limits by placing them on features, tasks, or both, to control how work is executed within a Sprint.

As an example, you can set a task limit equal to your team size multiplied by 1.5. Thus if your team has 8 members, you would never allow more than 12 tasks in flight at any one time.

Among other things, WIP limits will decrease the thrashing that is created as individuals start a task, then move to another before it is complete. The WIP limit will also make it easier to track progress within a Sprint as your burndown charts will be more meaningful earlier.

You can start applying the concepts immediately by evaluating current WIP and providing input to the team if the number of in-process features or tasks exceeds a reasonable limit, such as more than 2 open features (obviously dependent on the context of team and feature size) or more than 2 open tasks per team member.

Closing

Much of what is new, is an extension of what has proven to work in the past, so if you are not already applying them, consider the concepts of generalizing specialists, swarming and WIP limits to improve the effectiveness of your teams.

PODCAST: Bud Phillips on Agile and Lean at Capital One

One of the best podcast interviews I've heard is the one that Bob Payne conducted with Bud Phillips in 2006 at the Agile conference.  Bud, then a business-side VP of Decisioning Services at Capital One, really brought out some of the best aspects of Agile methods: 

• Taking the Lean perspective on Agile;
  
• Making the initial transition from Waterfall to Lean-Agile;
• The positive impact on team and associate satisfaction, "associates blossom....it's a positive virtuously driven cycle";
  
• The positive impact on customers, including a shared definition of what's valuable, "not functional perfection, but the total outcome of all the work put together" and a closer collaboration with IT teams;
• The "enormous human dimension" of Agile -- how people start to work in a different, trusting way;
• The ability to change incrementally more easily because Agile in this group was business-side driven as  (as opposed to being a purely IT-driven initiative); and
• How Agile challenges leaders, and how they work, allow for room and inspire.

I strongly recommend it.  Here's a link to it: http://agiletoolkit.libsyn.com/index.php?post_id=116686.  

Do let me know what you think of it, too!

Tele-seminar on June 18: Agile PMO

On June 18th, 2009 I'll be presenting a tele-seminar on scaling Scrum beyond individual projects with an Agile PMO.   Check this link for more details: http://www.mmpubs.com/catalog/18-june-2009-the-agile-pmo-teleseminar-p-297.html.