This week's book giveaway is in the Reactive Progamming forum. We're giving away four copies of Reactive Streams in Java: Concurrency with RxJava, Reactor, and Akka Streams and have Adam Davis on-line! See this thread for details.
Hi, I'm a software developer working an agile project and I came into this project in the middle of it, so I never got to see what happened (such as scheduling) at the beginning of the project. Anyway, I've been doing a lot of reading on creating a product backlog using story points, and one of my questions is, how do we translate that to actual time without going into too much detail up front? Inevitably, at the beginning of the project (or even if I am writing a proposal for a new project), someone will ask, "How long will this take?" I understand that it's impossible to give an accurate estimate that early on, but I have to give some estimate? Should I start trying to estimate what our velocity will be based on previous projects? And what if it's a new project? Any thoughts?
- estimate in ideal time and apply an arbitrary factor between e and pi (for example 3)
- estimate in whatever unit you are used to and use past experience with similar projects and/or teams to guess how that translates to real project time
- after estimating the project, develop two or three representative features, and use that experience to extrapolate the duration of the whole project
Especially the first approach works stupendously well.
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
posted 11 years ago
Thanks Ilja. You'd think by now us developers would multiply our own estimates by 3 so we can estimate correctly. If only we weren't so optimistic...