Since we didn’t have anyone on the extremes, we elected to explore the learnings a bit differently as a group. We formulated two similar questions on informing one side what they could learn from the other side. Originally we planned to break into the two camps people indicated they leaned towards, but since we didn’t have that division, we adapted the questions to explore each side.
What would you tell a “Proestimates” person they can learn from the “No Estimates “crowd?
Remember, these are learnings that may be helpful, we’re not asking you to give up your need to estimate for any length of time, though there is a request to try dropping them at least once and see what is like with your team.
- Estimates have a cost. Make sure the value is greater than the cost.
- Have you assessed if your estimations actually provide value?
- Treat estimates (of value in particular) as a hypothesis
- A team gets more self-organized gradually, so estimates will increase in both accuracy and precision over time and yet also become less necessary
- Estimation does not encourage sharing of risk between parties (it provides a scapegoat mechanism)
- Estimation creates longer feedback cycles
- The very way estimation is done matters, and some ways can turn people off to it.
- Not estimating does not mean not planning/No estimates ≠ No planning (you change the focus of what you talk about)
- Question assumptions
- I don’t care if the project ends tomorrow (invokes a head in the sand attitude – the estimate produces false confidence of project necessity)
- Effective measurement systems can improve estimates (and reduce the need for them); estimation can reduce the desire to improve the measurement system
- Keep estimating, but ensure it is really the right level of fidelity and not overkill
- Stay focused on working software
- Delivering working software is more fun than doing so with estimates – try it before judging
- It’s OK to acknowledge you don’t have perfect knowledge
- Know alternatives to answering questions other than just estimates
- Ask WHY you are estimating/Question WHY you are asking for or providing estimates
- Reducing the time to estimate can give you more time towards delivery
- Devolution is real, meaning estimation is not a necessity under all circumstances, don’t stay stuck in the past
What would you tell a “No Estimates“ person they can learn from the “Proestimates” crowd?
Remember, these are learnings that may be helpful, we’re not asking you to take up doing estimates, though as you’ll see estimation gets a bad rap due to other issues in the system.
- The conversations that take place during estimating can help a team arrive at a shared understanding of the work
- Don’t discards value that can come from estimates and the estimating process
- Estimates can drive learning of a shared understanding of a task
- Estimations make teams be better prepared for clarity and visibility
- You need to do something to set goals/expectations
- Estimates are scapegoats for other organizational dysfunctions (such as their misuse)/don’t throw out estimates and keep broader organizational dysfunction
- Estimates can show many different things that could be amiss in a team/organization
- Points, time, & $ are not the only things we estimate
- The right estimation gives/makes better release planning
- Lots of implied estimations occur
- Many of our assumptions (e.g. what is most valuable) are intuitive estimates
- Unless you measure how will the team manage?
- Measure more
- Focus more on testable hypotheses if not estimating
Next up in the 4th session, what assumptions are we making when we decide to skip estimation? This produced some interesting results and likewise we realized that some assumptions are the same between the two, though there were some subtle differences in how they get worded. Like before we explored the first set then discussed those we felt had significant difference.
The 3rd session began our exploration of assumptions underneath making estimations. We explored the first 12 in detail, and then hit ones that significantly differed from these 12 in the list below the line. (People voted on their individual top assumption by placing it above the line.)
Agile Dialogues 