Someone said in a recent discussion thread “Estimating with the poker and the story points is very difficult to translate to time and money”. I’ve decided that story points are a great tool even for client-type estimation.
Before Agile, when estimating a large number of features or customer requirements, I’d first decide large-medium-small. Small would be 1 day, medium 5 and large 10 unless I thought it was REALLY large then would compare it to something I knew we’d done before. For example, anything that affected an import always seemed to take 4 weeks so I’d give them 20 days. Or a new module = 3 months. That’s all the story points are doing – giving relative sizing to projects too big for a developer to realistically know how to estimate it.
Story point work nicely because they are a series (I like the Fibonacci Series) which avoids wasting time with decisions like “Is it 5 days or 6 days?” Or worse, “Is it 30 days or 35 days?” I find that developers are pretty good at estimating 1, 2, 3, and maybe 5 day tasks. Anything larger needs to get broken down to obtain accurate estimates. But since up front clients want an initial approximate estimate, tell the developers to think of the story point as 1 day (I think most do anyway) and play poker. If you want more than just a “ballpark” estimate, then for anything > 5 points, split the stories. Stick with Story points initially – split 8 point tasks into a 3 and a 5 point story, etc. It helps if you have a tool that lets you easily split tasks and update story points.
After the project kicks off, have the developers convert points to hours (not directly points to hours but to update with real estimates like if some thing take 4 hours (we don’t user ½ story points) or 32 (between the 3 point and 5 point) – to get more accuracy). If you have a tool that tracks hours and part of your process is the developers continue to update the remaining hour estimates, that works well. We have a good date estimation tool then that shows the end date based on developer “load” (similar to estimating based on “confidence” but “load” is more explainable to development managers). I’ve found through the years it’s a mistake to assume that when a developer says it will take them 2 days that the code will get checked into the code management system in 2 calendar days. Two days in the developer’s thought process is time spent coding. Most employees typically have other things they do besides straight coding: meetings, discussions with the product owner/manager, client issues, bug fixing unrelated to the new efforts. So our tool lets the manager put in the ‘load’ and even a % by person (if you have a developer on your project only half time for example). With that type of tool, I and my development managers successfully kept projects on-track release after release. Our Board of Directors was very impressed year after year 🙂
Sometimes even with good up-front task management, during the process you may encounter an estimation error or something that was missed that will extend the timeline. Having a tool to keep checking release date projections helps identify such problems earlier than later. Typically projects will take as long as they will take. The earlier clients are aware that something ended up bigger than initially anticipated, the better.
And having broken the project down into manageable tasks, you can review the more granular features and functions with your client in the event that the revised estimates are not acceptable and together determine if some features should be postponed or the schedule/cost increase accepted.
Software 2020’s Date Estimator and other features make it easy to estimate and work effectively.