Reddit 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.

Computers & Technology
Books
Computer Programming
Software Design, Testing & Engineering
Software Development
Agile Estimating and Planning
Prentice Hall
Check price on Amazon

5 Reddit comments about Agile Estimating and Planning:

u/gracebatmonkey · 6 pointsr/agile

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:

  1. Yes, I worked with a team that did this. They had a good understanding of the needs of their qa team and were conscientious about documentation and smooth code review protocol, so that helped a lot. If something would take more than the available hours in a sprint, they'd break it down further to discrete work parts. They did move away from it after they had a better concept of capacity and velocity as expressed in story points. I think they were an exception, rather than the rule, however, and for most any other team I'd likely recommend entirely different approaches, since it's easy to get bogged down in the translation.

  2. You would take a new benchmark story. Partly because as the team gets more mature, something estimated at 3pts at one point in time would now maybe be 2, and partly because effort needs to be evaluated in context, so an older work item would have staled in relevance.

  3. This is more of a learning to estimate technique than one that would stay in the team's toolbox forever, maybe to get pulled out again in the future to break down particularly sticky specs/reqs. At least one of the articles above discusses this method in detail, perhaps making it easier to decide if it's worth using.
u/shaziro · 3 pointsr/agile

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.

u/dkode80 · 3 pointsr/agile

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

u/Caleb6 · 1 pointr/projectmanagement

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:

  1. An iteration ( 10 biz days, 10 devs @ $250/day ea.) costs $25,000
  2. 30 Features (User stories) defined at an avg of 5 ideal days each. In reality you would not average here but sum individual US estimations.
  3. That's 150 ideal days.
  4. Real throughput is 8 ideal days per dev per iteration (overhead of 20%)
  5. 150/8 =18.75 iterations - call it 20 to add a bit of slack.
  6. 20 iterations = $500k

    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.