Exceptional Agile Planning and Tracking

David Tuma

Agile methods have transformed software development, improving customer satisfaction and accelerating speed-to-value. Yet many teams routinely hit an “agile glass ceiling.” If you’ve grappled with missed commitments, schedule overruns, and unpredictable delivery despite following agile best practices, you are not alone.

This presentation describes a practical, proven approach to planning and tracking that helps teams to be more agile as they make and keep commitments, improve predictability, and delight their customers. You’ll also see a newly-available suite of tools that makes these techniques simple to adopt and integrate into existing agile workflows.

https://softwareexcellencealliance.org/exceptional-agile-planning-and-tracking/

Attendee

MD: In your slide on backlog vs. collaboration time - isn't it standard practice to reserve an hour or two a day for non-development work, like meetings and admin (i.e., the collaboration items you mentioned)?

David Tuma

Attendee Yes, I'd say that's standard practice; but based on the data we see from real-world teams in our million-hour data warehouse, an hour or two isn't enough. The median collaboration level was 68%; meaning the typical full-time individual spends almost 5.5 hours per 8-hour workday collaborating with others. Only 4% percent of full-time individuals were able to get their collaboration time down to the 2 hours per day you quote.

Those statistics are definitely surprising, but they are based on a data from thousands of people over a 12-year period. I've tracked this myself over the years and can attest that its tremendously difficult to get to 25 backlog hours per week, and even harder to sustain it. So if you're only setting aside a couple of hours per day, you're not setting aside enough. And if you're not tracking it, you'd never even know - you'd just miss your commitments and not understand why.

Steve Shook

I've worked with teams that don't care to log their time, and teams that have their own unique ways of making estimates. Will the practices you've described still work for them?

David Tuma

Steve Shook That's a great question. I'll start with the time-tracking part.

First: it's no secret that very few agile teams track time; and they are fully correct in making that decision because their tools do nothing with time log data. If your tool doesn't bother analyzing some piece of data, it would be a waste of time to collect it.

The algorithm I described in this presentation is different. It peels apart the two independent contributions to velocity; and those two new parts have direct relationships to actual time. That means a tool can use time logs in powerful ways to close the feedback loop and give you better insights into progress, better root-cause analysis, and better forecasts. It only takes a few minutes per day to capture the data, and you get such incredible insights in return, so I think it's a no-brainer.

But if your team has a learned aversion to time tracking, it's absolutely not required. The plan, actual, replan, and forecast lines can all be calculated regardless; so you can benefit from the continuous replanning pipeline and the self-healing forecasts. What you lose is the tool's ability to help you understand why you're behind, and what corrective action to take; and these are insights that empower you to take control. If you decide in the future that you could benefit from more predictability, you can always adopt time logging at that point. You're free to adopt as much or as little maturity as you need to meet your customer's requirements.

As for estimation: there are a lot of different approaches; and I believe teams should choose the estimating methods that work best for them. As a tool developer I love hearing about these different approaches so I can make sure I support them in the scheduling engine. Internally, the engine translates these different estimating techniques to backlog time purely so it can perform an apples-to-apples comparison against team capacity. This translation step creates the flexibility to use different estimating methods within this scheduling approach. And this includes #NoEstimates teams - it's just a matter of crunching historical completion data and using the resulting average for future stories.

Jeff Schwalb

Is there a list of possible future plug-in capabilities you plan to build? How can I find out more about that list? How can I add to that list?

David Tuma

Jeff Schwalb Yes! As I mentioned, the current MVP provides all of the capabilities I demonstrated in the presentation today. Click here to visit the page describing the MVP. At the bottom of that page, you'll see a Roadmap section describing items that we plan to work on soon.

If you have ideas you'd like to add to the list, click here and fill out the form to become a partner and sponsor. We'd like input from a diverse set of teams to make sure the future functionality is flexible enough to support a variety of workflows.

Attendee

Max Hinkley: Do you find that when people work with velocity, their incentives end up backwards? That they artificially try to improve velocity by rushing through code without adequate design?

David Tuma

Attendee I wouldn't say that, because every team is different. I have read articles discussing how, if you're not careful, velocity can turn into a vanity metric; where you end up optimizing for the wrong thing. But velocity doesn't have a monopoly on that problem; it's something you have to watch for no matter which planning and tracking mechanism you use.

I will say that velocity was originally meant to track the value you're delivering to the customer and to make sure you're delivering value every sprint. If you maintain a focus on customer value velocity can still be a great way to track it. And velocity also turned out to be a great way to produce quick, rough estimates for capacity planning. Because it succeeded so well at those two things and became so universally adopted, our industry has tended to reuse those same numbers for tracking progress and forecasting. That's unfortunate, because those are the areas where it breaks down. That breakdown can be the start of misaligned incentives for a team.

Steve Shook

Since we're on the subject of misaligned incentives: is there a concern that the kind of data and projections you're describing could be misunderstood or misused by managers or leadership? How do you guard against that?

David Tuma

Steve Shook Yes, that's a very valid concern. Just as developers can be incentivized by something like velocity to engage in the wrong behaviors, managers can look at a number and end up motivated toward the wrong thing too.

Since I'm a developer myself, I'm very sensitive to this concern. It's important to me to ensure the tools I build include the appropriate data protections - so managers aren't tempted to micromanage, customers aren't able to reconstruct productivity rates, and so on. I've been doing this for years so I have a fairly good idea where the bright lines fall; but this is an area where I look forward to hearing from many teams to make sure I'm meeting the needs of different organizations.