Reddit reviews Agile Estimating and Planning
We found 5 Reddit comments about Agile Estimating and Planning. Here are the top ones, ranked by their Reddit score.
Prentice Hall
We found 5 Reddit comments about Agile Estimating and Planning. Here are the top ones, ranked by their Reddit score.
Before anything else, there's a great book that helps with this whole thing: Agile Estimating and Planning
Next, there are lots of other approaches, and based on how you're explaining your understanding on the three methods you offered (and the benchmark example especially), I think you might find some clarity in reading through these resources:
8 Agile Estimation Techniques Beyond Planning Poker - I think this will help the team wrap their heads around what's being asked in expressing estimates with storypoints.
Fast Estimation - really good technique that cuts through the noise.
Agile Project Estimation Techniques from PMI- because of your questions relating to release intervals, I think reading through this article that goes into detail about some of the techniques already mentioned may simplify your thinking on this, especially the section on "Determining Budget".
Finally, answers to your specific questions:
Agile Estimation and Planning recommends story pointing. You story point all of the work based on effort. A story that is 2 story points is predicted to take twice as long as a story that is 1 story point. At the end of each sprint, you add up the amount of story points worth of user stories that were closed out in the sprint (no partial credit for partially completed user stories). This is the velocity. You can take the average of the velocity over the past 8 sprints to predict future performance.
The benefit of this is that you only have to think about how long stories will take relative to each other. Two people might disagree about how many hours a user story will take but agree on how long a user story will take relative to another user story.
The downside is that your velocity calculations may not be an accurate predictor of future performance if your team composition/size is constantly changing.
I don't know for sure what you mean here by pointing in time. If you are just taking user stories and converting story points to hours or something like that (as opposed to using story points to calculate velocity), then that is not really any different than just estimating in hours. See https://www.mountaingoatsoftware.com/blog/dont-equate-story-points-to-hours for more information.
This one is pretty good:
https://www.amazon.co.uk/Agile-Estimating-Planning-Robert-Martin/dp/0131479415
Can't express how good this one is. Overall, any of Mike cohn' books are all great
https://www.amazon.com/dp/0131479415/ref=cm_sw_r_cp_awdb_t1_scbOAbVTE20NV
Edit: user stories applied is another one of his greats:
https://www.amazon.com/dp/0321205685/ref=cm_sw_r_cp_awdb_t1_WdbOAbZP5TPTC
I wouldn't say that budgeting is horrible in agile. Agile simplifies budgeting into iteration costs, and then estimates feature sets across iterations. In a very simplified example, if:
Where agile shines regarding scheduling is that the features are developed in the order of product manager / user value - and that value is recognized periodically with interim working product releases. This allows you to realize incoming cash flows earlier than a standard waterfall approach.
Where a scheduler would shine in Agile is in the statistical weighting and ordering of feature priority - not necessarily in the estimation of duration of each Feature / User Story. I highly recommend [Agile Estimating & Planning] (http://www.amazon.com/Agile-Estimating-Planning-Mike-Cohn/dp/0131479415) by Mike Cohn. IMO - the real trick to Agile is the proper ordering of development. If you hash that, you lose the early cash realization, and you can end up with a product that does not meet requirements as you fail to deliver core features before you run out of time/money.