How often have we been faced with this situation? A stakeholder comes to you, perhaps taps you on the shoulder & asks 'Hey, if you could estimate when this will be complete, when would it be?'
You provide an honest answer, you're keen to demonstrate transparency, and yet the number you give, is then anchored as the deadline. ๐๐'๐ ๐ณ๐ถ๐ป๐ถ๐๐ฒ, ๐ฎ๐ป๐ฑ ๐๐ผ๐'๐ฟ๐ฒ ๐ต๐ฒ๐น๐ฑ ๐๐ผ ๐ถ๐.
The term deadline has a history entirely unrelated to business & yet it has become accepted business language.
The word is linked back to the American Civil War in 1863, diaries kept by soldiers referred to the line that was drawn around a prison, where if a prisoner passes it, they risk being shot.
Deadlines for me, don't have much place in an agile world.
There are exceptions & we need to be pragmatic. Regulatory matters & urgent fixes are examples. Realistically, we will sometimes need to work with deadlines, however these should be the exception, not the rule.
๐๐ฐ๐๐ถ๐ผ๐ป๐ฎ๐ฏ๐น๐ฒ ๐๐ฎ๐ธ๐ฒ๐ฎ๐๐ฎ๐๐
- Encourage teams to provide ๐ฒ๐๐๐ถ๐บ๐ฎ๐๐ฒ๐, ๐ป๐ผ๐ ๐ฑ๐ฒ๐ฎ๐ฑ๐น๐ถ๐ป๐ฒ๐.
Estimates are exactly that, an estimate, an educated guess based on knowledge and experience. They are based on assumptions and the knowledge of the situation at that given time. At the time an estimate is given, an assumption may be true. At the time the estimated date draws closer, that may no longer be true and the estimate should be revised.
This isn't a failure, or a negative on behalf of the estimator. Something outside of their control changed, and thus, so should the estimate.
- Rather than use RAG status, consider confidence voting
I've long discovered that I don't like RAG statuses. How often have you seen 'Watermelon' RAG status, where everything is green on the outside, but upon a little digging, it's actually very red.
When used correctly, RAG can be a useful flag, an indicator that something needs attention, but more often than not, it's used to suggest something has failed, something is broken, someone isn't doing good enough, and that's not usually the case.
Why not try confidence voting instead? Allow the team to provide a low, medium or high level of confidence that the piece of work will be completed as per the estimate. This is far less likely to be gamed in my experience.
- Acknowledge & understand that in an agile and VUCA world, things change that may impact estimates. This is ok
Every day, we learn something new. We are faced with new knowledge, something changes, we react. Estimates change, and we shouldn't respond to this negatively.
- Consider using the agile estimation game to demonstrate the challenges around estimation
More details on this game and how to play it here; https://www.youtube.com/watch?v=LxOMhmFwgm0
How do you handle this scenario? How do you educate those that are always working with deadlines?
Comments