With software estimation you've only realistically got a choice of 5 mins, 1 hour, 1-2 days, about a week, and then all bets are off. — Rob Bowley (@robbowley) September 18, 2011 Read more →
EppsNet Archive: Software Estimation
Aside
Ron Jeffries: Estimation is Evil
Aside
Joshua Kerievsky: Stop Using Story Points
Aside
Jeff Sutherland: Scrum: Why Story Points Are Better Than Hours
How’s That WBS Working for You?
Michael James posted this annotated job listing in the Scrum group on Yahoo . . . [Redacted] is looking for a dedicated and experienced application developer [blah blah blah] to ensure delivery of high quality artifacts, to adhere and to follow [Redacted]’s SDLC. This is an excellent opportunity [blah blah blah] well-known Fortune 50 company. Tasks and responsibilities [clip] Provide accurate and timely estimates (work breakdown schedules) Must have proven ability to provide project estimates and work-breakdown schedules And you know these guys are getting great results from their precise WBS and SDLC because of these lines: Must be extremely responsive, able to work under pressure in crisis with a strong sense of urgency 24/7 on call responsibilities on a rotational basis Read more →
Estimation
Guarantees vs. Commitments
A thought exercise: “How long will it take you to get to work tomorrow? Can you guarantee it? To give us a guarantee, you’d probably put a buffer on your answer first. I guarantee a team working to put together software for the next two weeks is engaged in something a lot less well understood than a daily commute. We can put in a buffer – promise less – to give you a guarantee, or we can work from our estimates and do our best.” — William Wake Read more →
Completion Percentages
It ain’t over till it’s over. — Yogi Berra A project manager reports that her project is “48 percent complete.” In terms of what, I wonder? Calendar time? Cost? Effort? I know it’s not 48 percent complete in terms of functionality because there hasn’t been any working code delivered, just a bunch of documents. One approach that makes sense to me is to express completion percentages in terms of implemented requirements. For example, if you have 100 functional requirements, and 48 of them have been successfully implemented, then you’re 48 percent complete! Actually, I oversimplified that a little . . . All requirements are not created equal: Because some requirements cost more to implement than others, and some requirements have a greater business value than others, you could assign relative cost and relative value numbers to each requirement, and calculate completion percentages accordingly. This is good both for measuring the… Read more →