Mike Cohn of Mountain Goat Software writes about Agile, Scrum, estimating, and sprint planning.
HN commenters cite it as a resource on estimating and planning, while one argues its Scrum description reads as rigid and leaves little room for adaptability.
There’s a well-established Agile technique that in my experience actually succeeds at producing usable estimates.
The PM and team lead write a description of a task, and the whole team reads it together, thinks about it privately, and then votes on its complexity simultaneously using a unitless Fibonacci scale: 1,2,3,5,8,13,21... There's also a 0.5 used for the complexity of literally just fixing a typo.
Because nobody reveals their number until everyone is ready, there's little anchoring, adjustment or conformity bias which are terribly detrimental to estimations.
If the votes cluster tightly, the team settles on the convergent value. If there’s a large spread, the people at the extremes explain their thinking. That’s the real value of the exercise: the outliers surface hidden assumptions, unknowns, and risks. The junior dev might be seeing something the rest of the team missed. That's's great. The team revisits the task with that new information and votes again. The cycle repeats until there’s genuine agreement.
This process works because it forces independent judgment, exposes the model-gap between team members, and prevents anchoring. It’s the only estimation approach I’ve seen that reliably produces numbers the team can stand behind.
It's important that the scores be unitless estimates of complexity, not time. How complex is this task? not How long will this task take?
One team had a rule that if a task had complexity 21, it should be broken down into smaller…
So much of "Agile" is an attempt to "patch" the top-down, closed-allocation organization that is simply incapable of hitting technical high notes no matter how much it spends or how many people it hires.
Since organizations are tough to change and all dysfunctions have champions (some deeply hidden) the "Agile" ends up having to make smaller and smaller motions while its desire for control, as the velocity in an irrotational vortex, gets stronger. Then it devolves into micromanagement, as discussed here: http://www.mountaingoatsoftware.com/blog/ssssh....agile-is-all-about-micromanaging
The reality is that the future just has no use for closed-allocation tech companies. Every tech company needs to decide either to play for real and try to excel (open allocation, highly selective hiring) or GTFO and do something else.
Scrum is a formational hack, but closed allocation is a foundational problem and, if technical excellence is needed, a show-stopper.
That's not how it's presented in real life.
Read something like this:
https://www.mountaingoatsoftware.com/agile/scrum
All about what has to be done, with a formal role of scrum master.
Phrases like these brook no adaptability:
On each day of the sprint, all team members should attend a daily Scrum meeting, including the ScrumMaster and the product owner
on the first day of a sprint and during the planning meeting
Another activity in Scrum project management is the sprint retrospective at the end of each sprint. The whole team participates in this meeting
Management take Scrum as a set of rules to follow and then use it to micro-manage everyone. Scrum masters end up as middle managers. Daily stand-ups turn in to daily justify your worth.
I'm sure everyone has their own idiosyncratic interpretations, but I believe I've got enough experience to tell you that what I'm explaining is pretty standard.
Here are literally the top two Google results for "story points" and they both seem to align entirely with what I said:
https://www.atlassian.com/agile/project-management/estimation
https://www.mountaingoatsoftware.com/blog/what-are-story-points
I don't doubt that what you're describing as story points is something somebody told you. I'm just telling you that their definition was highly idiosyncratic and extremely non-standard. When discussing these things, using the standard definitions is helpful.
In the Kano Model this is called an exciter.
http://en.wikipedia.org/wiki/Kano_model
The greatest problem with Customer Development and the concept of the Minimum Viable Product is that there is no rigorous classification for quality and value.
A great book to read with respect to product management is Agile Product Management with Scrum.
http://www.amazon.com/exec/obidos/ASIN/0321605780
There are also slides here:
http://www.mountaingoatsoftware.com/system/presentation/file/11/SDBP05_AgileProductMgmt.pdf
Something I took from several articles is, most managers don't really need an estimate - what they need is a commitment, and/or a budget (and the estimate is an input to generate said commitment or budget).
https://www.mountaingoatsoftware.com/blog/separate-estimating-from-committing
https://hbr.org/2014/12/your-agile-project-needs-a-budget-not-an-estimate