Navigating estimates and due dates in Agile
Software estimates are hard. Even with deep knowledge of the technologies being used, not to mention the system you’re working on, we’ve all run into issues we didn’t see coming. And when it’s plain sailing, what if you get interrupted — or asked to do something else before you’re ready?
In looking to understand more about why estimation is hard, I came across an article that’s well worth a few minutes of your time — “ Why are software estimates so hard? “ (codebots.com)
A couple of takeaways from that post. Firstly, humans can be overoptimistic. Secondly, while too much pressure can affect quality, a lack of any time pressure can do the same. I find this very interesting. With no pressure at all, there’s no urgency to finish the task at hand.
With that in mind, I’d like to talk a bit about setting due dates for tasks.
From waterfall to Agile
Setting dates reminds me of the days of waterfall project management. Microsoft Project plans with tasks leading into other tasks. Everything was mapped out as a dependency, with tasks linked to other tasks. A lot of a Project Manager’s day seemed to be spent fiddling with dates. The requirements were given a block of time at the start. Design was given a block after that. Then development. Then testing. All as big blocks, and never overlapping. Things overran, and testing got squeezed. Then the whole project goes live in one big chunk. No wonder so many IT projects of this nature overrun or go wrong when they go live.
In Agile, there’s a much more fluid way of working. We maintain an ordered backlog of digestible chunks of functionality (stories). When the team is ready to pick up a new task, the topmost item from the backlog gets marked as “in progress”. When it’s done, it moves to “Done”. Rinse and repeat. We’re free of the shackles of Gantt charts and looming deadlines. We’re no longer doing all of the development as a massive chunk, and then throwing the entire project to the testers. We’re able to discuss things when picking up a story, instead of being told that the spec is signed off and can’t be changed. And we’re no longer deploying an entire project in one go. (Well, most of the time.)
However, when a stakeholder wants something that’s important to them but you’ve got a bunch of other super high priority tasks in the way, the stakeholder may end up waiting a while for their request to be worked on.
Inevitably, you’re going to be asked a deceptively tough question: when will this get done?
And when your backlog is feel a little… well, backlogged… it can be difficult to see when a specific request will land.
Getting estimates in place
The first step is keeping an ordered backlog. Not the whole thing, mind you. I aim to keep the top 10–20 items in order — especially if they’re medium or large in size. This means you’re not needing to think about where potentially 100+ items fit into an arbitrary plan.
When things are near the top of the backlog, this is the time to talk to the team about details. Help the team understand what each task is about. If you can’t explain it yourself, bring someone in who can. Make sure the task has a clear description — and add to it as needed.
When the team understands the task at hand and has started thinking about how to do it, the team should be able to estimate the task. Whether you use story points or t-shirt sizes, getting a size relative to the other items in the backlog can be highly valuable.
But we’ve still got that question to answer. When will this be done?
Setting a due date
Let’s be clear here. I do not advocate setting a date for every task. I don’t see much point in setting dates for small tasks or most things that will comfortably fit inside a week.
But I do see some benefit in agreeing a target date for high priority tasks where there’s a degree of uncertainty, or where the work is big, complex, or risky. The key here is collaboration with the team — agreeing a sensible date with them — and not imposing one (unless there’s a legal deadline, for instance).
Dates come with a strong caveat. They are not guarantees, and should not be widely shared. The team should not be held to account if they miss a date by a day or two. If this is done, the team will lose trust in the person holding them to account, and future estimates will be inflated to compensate. If this then leads to estimates being reduced to reach a “true estimate”, trust will erode further.
Don’t fall into this trap. Instead, dates should be used as a gauge to determine if a task is on track, at risk, or off track.
For example, let’s say the team has estimated a task as a Large. They will be able to start the work on Monday 1st February. A sensible target date is suggested as Friday 12th February. Daily standups (or whatever method you use for keeping in touch) can talk as normal about how things are going. As the target date approaches, how confident does the team feel about delivering the task?
Without any form of date, large tasks can roll on and on for some time. Having some kind of milestone, or checkpoint, gives you something to aim for.
Why not just use Scrum?
This crossed my mind as I was writing the last couple of paragraphs. You could add some structure by working in a 2 week sprint. Then you always have a recurring date you’re aiming for.
I think Scrum can work well for teams who are new to Agile, who lack structure and want some, and for some types of projects. For mature teams, or where there is a high degree of variance in the type and length of work, Kanban might be better.
Scrum might work — but I don’t think it’s the only solution.
In summary
Setting dates for software development tasks needs to be done with careful consideration. Estimation is hard, and dates should not be taken as a guarantee. Holding a team accountable for a wrong estimate can lead to a loss of trust.
Instead, use dates in collaboration with a team to help them determine whether a task is on track, at risk, or off track — and work with them to find ways to help out when things do go off track.
Because sometimes — they will.
Originally published at https://www.benbarden.com on January 31, 2021.
