I continue to see discussions on Agile and Lean forums about whether it is good to track this or estimate that. The answers 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.