To Estimate or Not? To Track or Not? – Those Are The Questions!

I continue to see discussions on Agile and Lean forums about whether it is good to track this or estimate that.  The Shakespeareanswers are like most things with Agile and Lean, they are contextual, but consider the following.

In Lean-Agile there are really 3 types of costs; value add, transactional and coordination. Value-add costs create value for the customer, the other two do not.

Estimation and tracking are a mix of transactional and coordination costs. They add no value to the customer hence they should be minimized. That said, the data collected through these two non-value add costs can be important for planning, communicating and driving an understanding of impediments and hypothesizing improvements.

Data is valuable for making pragmatic improvement decisions. If not, we wouldn’t have 5 senses collecting it. Eric Ries’ term ‘validated learning’ is appropriate here. I’m a big fan of right brain, intuitive reasoning but many in management are not…they need the data.

Knowing how much unplanned work (value demand and failure demand) a team has can be seen on a board just by using different color cards or different shaped cards. We are visual creatures and visual stimuli have the most impact with us.

We know that the enemy of predictability is variability in all its forms. Scrum was originally predicated on no interruptions. This isn’t a reality in many businesses for a variety of reasons. The planning ceremonies for Scrum for even a 2 week Sprint can become themselves wasteful if applied in the wrong context. For example, I recently visited a company that had mandated the use of Scrum, even in their support group.  They would hold a Sprint planning meeting on the first day of their Sprint  and 2 days later 30+% of their Sprint Backlog had changed so they would have to engage in regular re-planning to adjust their forecast. It was by estimating and tracking the particulars of their work that the team was able to convince management that Kanban was a better alternative.  After that the level of estimation and tracking reduced.

If you were to insist on practicing Scrum in such an environment, be sure you can explain why velocity is where it is. This will require understanding the nature of the work being undertaken by the team, which means having data, which will mean some rudimentary form of data capture and tracking. In Scrum, this is an area of service to the team that the Scrum Master can undertake to improve transparency and the type and quality of the data being radiated from the team. This aids the team and wider organization in making better plans and better decisions.

Passively watching velocity, lead time or cycle time change as you change practice or policy in a system through retrospection, hoping the changes improves things doesn’t cut it. Validated learning requires knowing what you expect to change from your experiment and what you will measure to know if your change hypothesis was correct. Such contextual needs for data should drive the amount of estimation and tracking a team undertakes in its efforts

One of my favorite Agile sayings is “we adapt the plan to fit reality and not reality to fit the plan”. Don’t forget this when choosing an approach to execute your organization’s work in its particular context.


About Mike DePaoli

Mike DePaoli has been contributing to the IT community for over two decades and practicing agile and lean approaches to software development since 1996 in roles from programmer to CTO. His evolved approach to crafting successful lean-agile software development organizations was forged by the meaningful challenges he undertook at prior employers and as an Agile Coach at companies such as eBay, Adobe Systems, AOL, NetApp, Disney, Boeing, EMC, and Trizetto. Mike’s area of expertise is helping organizations craft strategic change initiatives that educate on and establish agile and lean values, principles and practices at every tier of the organization. Mike applies systematic thinking with a multi-discipline approach to his work. Mike is a Certified SAFe Agilist, Certified Scrum Professional, Certified Scrum Master (CSM) and Certified Scrum Product Owner (CSPO). He is a highly-regarded speaker in the Agile community having spoken at Agile conferences in North America, South America and Europe. He is currently based in the San Francisco Bay Area.

No comments yet... Be the first to leave a reply!

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

Lean-Agile Leadership - Exploring the Creation of Fertile Environments and Culture for Lean-Agile Software Development


Lean-Agile Leadership - Exploring the Creation of Fertile Environments and Culture for Lean-Agile Software Development

The Agile Horizon

Lean-Agile Leadership - Exploring the Creation of Fertile Environments and Culture for Lean-Agile Software Development

%d bloggers like this: