Note: This report is under development and will be available soon.

Challenge to avoid

Developers are highly motivated to produce results and avoid rework if possible. While this motivation is good, it has a dark side to it. That is the temptation to look ahead and build something related to what they are working on now, but that isn’t part of the current feature being focused on. The motivations are good, but it can delay the delivery of a feature that has been determined to be more important than the future work being worked on.

Why this is important

Development teams are supposed to work on features in the order specified by their Product Owner. While teams know this, it is not always followed. Sometimes with good reason, but more often not developers are not understanding the importance of only building what is needed at the moment. Doing more always delays the items identified as more important and is often discovered to be unecessary as we learn more about what we want to build. Targetprocess provides a report of feature completion over time that makes when people are working ahead readily visible.  An example is shown in Figure 1.

 

 

 

 

 

 

 

 

 

 

 

How to use this report

First observe if there is work being done on future features.  The more of these there are the likely it will be slowing down the more highly prioritized features and likely increase work in process to more than is needed. It is important, however, that this is not necessarily the wrong thing to be doing. Slowing down current work sometimes is worthwhile the investment in the future. But when teams know how to do emergent design this is less often than one would think.

After reviewing this data, the Product Owner and Agile team coach should have a discussion with the development team and see if working ahead is truly beneficial. If not, they should refocus the team on the most important features. Figure 2 represents actual data from a client where this was done after reviewing Figure 1.

Summary

Agile tells us to focus on the most important work. But old habits are often hard to break. The feature burn-up by release report provides information to Product Owners and Scrum masters so they can see if this is not happening. While the repor should not be used as a hammer on developers, it is a way to open up a conversation with them about why they are making the choices they are.