Estimates vs. #NoEstimates - DO PM 18th Jan 2017
•Download as PPTX, PDF•
0 likes•292 views
Talk for the Digital Project Management meet-up in Oxford (DO PM). Covers the topic of estimating and some of the arguments for and against the No Estimates movement.
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Estimates vs. #NoEstimates - DO PM 18th Jan 2017
Similar to Estimates vs. #NoEstimates - DO PM 18th Jan 2017 (20)
Recently uploaded
Recently uploaded (20)
Estimates vs. #NoEstimates - DO PM 18th Jan 2017
- 1. Estimates or #NoEstimates? DO PM, 18 January 2017
- 2. ● Improve our understanding of requirements ● Work out pricing ● Help prioritise ● Enable planning ● Set expectations ● Agree deadlines ● Coordinate resources ● Allow progress to be tracked ● Got told to ● Because that’s what we’ve always done Why do we estimate?
- 3. Why is estimating so difficult?
- 4. “There are known knowns. These are things we know that we know. There are known unknowns. That is to say, there are things that we know we don't know. But there are also unknown unknowns. There are things we don't know we don't know.” Donald Rumsfeld, US Secretary of Defense
- 5. Can you estimate the length of this pencil?
- 6. ● Unclear requirements ● Don’t have time (to explore the options) ● Incomplete information ● Incorrect information or assumptions ● Lack of previous experience ● Evolving requirements mid-project ● Estimates may differ depending on who’s due to do the work What makes estimating hard?
- 8. This guy started it... Woody Zuill Blog post about a successful software project completed without estimates Published in 2012 Shared via Twitter + started the hashtag #NoEstimates
- 9. The argument ● Because we’ve been doing estimates for so long, everyone assumes they’re a necessity ● Estimates are always inaccurate and therefore pointless ● Estimates are often padded by developers ● Estimates are a waste of valuable time The #NoEstimates camp
- 10. The counterargument ● Of course estimates are always wrong ● Refusing to provide estimates can be insensitive to the needs of the wider company ● Providing an estimate may impact multiple departments, teams, and individuals in ways the developer isn't privy to ● If you can't provide an estimate you won't get funding ● If your estimates are inaccurate, why not improve them? ● Businesses are built by predicting and analyzing market trends. Future forecasts are based on past performance. The #Estimates camp
- 12. Waterfall > Agile > #NoEstimates
Editor's Notes
- Estimates are an important part of what we do (agency or client-side) and how we do it. But how often do we take a step back to think about how we do this and whether we’re getting it right?
- There are some good reasons why we create estimates. And also a couple of not so good ones - can you spot them? Hands up if you find estimating easy.
- Firstly I want to start with a quote from a politician. I think this shows that planning foreign policy and software development have more in common than you might initially think…
- With a digital project we might be trying to estimate how long it’ll take to build before we even know what technology we’re going to use. Sometimes we get the opportunity to rethink our estimates once we know a bit more about what we’re building and what’s important from a users’ and a stakeholders’ point of view, but not always. That’s a bit crazy when you stop to think about it. Would you like to try a little test to see how good we are at estimating? I’ll even show you a picture to help.
- Can anyone tell me how long this pencil is to the nearest centimetre? And for a bonus point: how much does it weigh? [Note down answers on the board] Actually this pencil is twice as long as a ‘normal’ pencil and 22 times heavier. 35 cm vs. 18 cm and 135 g vs. 6 g. You can see that by deliberately not providing enough context it makes it harder to estimate something that appears to be an everyday object and should have been fairly simple to guess the length and weight of.
- Summary of what makes estimating hard in our industry. Estimates have always been an integral part of the software development process. By estimating the amount of time, money, and effort it will take to reach project goals and outcomes, developers and team leaders can help managers and clients better predict budgets and meet project goals. That's the theory behind the widespread and often unquestioned use of estimates in the IT industry today.
- In recent years, however, developers have begun to question the effectiveness, and even the purpose, of using estimates to predict a project's cost and time line. A fierce debate has sprung up on Twitter, between those calling for an end to estimates and those who continue to argue for their use in a professional setting.
- When faced with a seemingly endless requirements document and asked for estimates on implementation, Zuill and his team took a somewhat radical approach: they identified what they considered to be the most important story in the document, then broke that story down into smaller tasks, and executed those tasks as swiftly as possible. Once the client was shown the initial win in the form of working software, they were less concerned with estimates and more willing to let the development team continue checking items off the to-do list. Sounds good huh? Zuill's team was able to shift their focus from estimating time worked to actually doing the work, and from projecting costs to cutting costs by simply diving in and getting down to business.
- Estimates are part of the software development process not because they're effective or beneficial, but because they've been a part of the process for so long that developers, managers, and team leaders assume they're a necessity. When developers are asked to estimate the amount of time and work it will take to complete a project, they're asked to predict the future in a way that can't possibly account for the complex factors that will impact the estimate. Encouraging mistrust between team members, managers, and clients. This can harm project transparency and even damage healthy working relationships. Instead of beginning the work, developers are forced to spend time and money creating estimates that aren't accurate to begin with and are therefore useless.
- That's why they're called "estimates!" The complicated needs of the company that reach far beyond their particular project. Estimates should therefore be considered an important professional courtesy, even if developers themselves prefer to work without them. That's just how businesses work. Inaccuracy isn't a reason to abandon best practices. Estimates, therefore, can be created by assessing the time, cost, and units of work completed in past projects and by projecting them onto the current project.
- That’s all fine and well. You might be thinking: I’m going to start doing projects without estimates right now. Or you might be thinking: what a load of old cobblers. For me what this shows is how important it is to question the established methods (sometimes) because if we do, new ways of doing things come out. And some of them might just work.
- If you wanted to consider the evolution of thinking around estimates then it might be interesting to consider it like this: Estimate everything upfront (or try) Estimate at the start of each sprint (assuming you’re using SCRUM) Don’t estimate And the debate continues. So next time you see a scenario like this, spare a thought for what it’s like to be on the other side of it...
- Pretty much every day in an agency.