I just came a cross 5 Reasons Why You Should Stop Estimating User Stories by Michael Dubakov. While I consider it an important practice to challenge everything I think this time the challenge is pretty weak and falls apart as soon as you start to analyse it. So lets do just that:
- You don't waste time on estimation This one is valid to some extend. If you don't gain anything by doing estimations you should stop NOW. But if you do it properly, you do get value out of an estimation. If you don't estimate you don't know how expensive a feature will be, so there is no reasonable way to decide if you want that feature or not. More importantly: real live has deadlines all over the place. You have to meet those. In order to do that you'll have to throw out features. You won't be able to react if you don't know that you will miss the deadline before you actually crossed it.
- You shouldnâ€™t explain to higher managers why it took soooo loooooooong This is only true if you have an extremely weak manager, going "Oh they don't do estimates, so I guess I just wait here until they are done." If you have a manager like that, look for a new job, you will need it pretty soon.
- You donâ€™t give promises that are hard to keep an estimate is NOT A PROMISE! If you or anybody else takes an estimate and turns it into a deadline, somebody is asking for trouble. If you build a garage, you don't measure (estimate) your car and make the door exactly that wide. You add some extra space so it actually fits through the door. Also making strong promises and making them happen is the way to success. Nobody gets any attention with "We might release some kind of software which might happen to be useful to somebody sometime when we are done" With this wimpy attitude you will get nowhere, not with your career and not with your product
- You donâ€™t put additional pressure on development team This is the same argument with the same mistake. If somebody tries to turn your estimates into deadline, educate him on the difference, but don't let somebody stupid dictate your development practices.
- You focus on really important things Here Michael makes the case that by estimating epics the team might get scared. I think the opposite is more likely. Who is more scared by lets say sharks or spiders or flying? The people knowing next to nothing about the subject? Or the people knowing a lot about it? People that know that sharks do have big, sharp teeth and a strong jaw to rip them through your flesh, but who also know that sharks seldomly attack people and how to avoid being considered prey? If you know how big an epic is and what parts of it make it big, you can make a decision about if, when and how to tackle it. So if anything this is an argument in favor for estimates.
Do your estimates, but ensure two things: You get value out of them, by using them to stear your development. Don't spend more time on it then necessary. Magic Estimation is in my experience a good way to do that.
Wan't to meet me in person to tell me how stupid I am? You can find me at the following events:
- Spring Data JDBC - New Kid on the block.
- Softwaredevelopment in the 21st century.
- Domain Driven Design mit Relationalen Datenbanken und Spring Data JDBC.
- Kerbal Space Program, Glücksspiel und Psychologie und was das mit dem (Berufs)leben zu tun hat.
- Javaland Freeletics
- Domain Driven Design mit relationalen Datenbanken und Spring Data JDBC
- The New Kid on the Block: Spring Data JDBC