Talk:Story Points Estimation

Revision as of 16:50, 22 September 2015

Mette: I like your idea and topic. You write that the Story Points estimation tool separates itself from other conventional tools, so remember maybe to discuss the different that separates this tool from other tools and why it is a good thing.

MistaJacob, reviewer 1

The feedback will be given in the form:

• My feedback
  • My feedback

OR

• Copy of your text
  • My feedback

Feedback

• The general formatting is almost as it’s supposed to be. There are only small corrections and fine-tuning, i.e. how to place your pictures in the right place so it don’t overlap to other sections, or that all the points in “Estimating using Hours” are all 1’s.
• Maybe consider sub-headings instead of bold under the section of Alternatives.
• The language is clear and easy to read, only with small number of places where i found typo’s. I will not comment this since it will be obvious to you when you read through your article for corrections.
• Remember to make the annotated bibliography

• I found the article relevant, with a good red thread through it. The length seems appropriate to what you want to convey.
• It was first under “Step 1” that i understood what it was all about. In the introduction you only talked about story points, and not what the story itself was.
  • So my suggestion is to include the initial idea of using a story, maybe an example, and not assume that the reader knows this in advance.
• Under step 5: The reason an Agile team should always stride towards breaking down large tasks is because the individual, smaller tasks become more manageable while it also facilitates easier Sprint-Planning, reduces the risk of over commitment as well as diminishes some estimation uncertainty.
  • formulation about the individual (maybe missing a ‘for’)
  • I assume sprint-planning is a step in agile PM, but i missed a link to explain it. Whether you want to explain it in more detail or give a link, of cause depends on who your ‘target reader’ is and the level of previous knowledge you assume to known by the reader.
• Realise that management often cares more about when the product will be delivered rather than how many hours still needs to be completed - if leveraged correctly this point of view may be turned into a benefit
  • I really like this. Good thinking to include information on how this cost can be turned into a benefit
• You talk about the time of the project as a measure for whether story points is recommended. Again it is about who your target reader is, but i missed some information about when a project is ‘large’ or how long a ‘long periods’ is; or is a couple of sprints 2 or 4, and does the length of the sprints matter, or only that you go through all 5 steps?
• Under “Estimating using Hours”: People are notoriously bad at gut-feel estimations.
  • link to my article (when it’s finished, i should talk about overestimation as a common cognitive bias)
• Under “Estimating using Hours”: A general formula could be (OD*1 + ED*4 + PD*1)/6
  • link to the PERT article that also uses OD ED and PD
• Under “Estimating using Hours”: Remember estimation uncertainty is often log-normally distributed
  • could be under the same point you made about people being notoriously bad at gut-feel estimations
• In the referenced examples, two teams have decided to use Story Points as a high level measure, while using hours as a low level measure for Sprint-planning. In both examples it is argued that Hours give a better chance of committing "to capacity" for a sprint so that you don't end up having idle developers towards the end of an iteration.
  • I eventually figured out that “the referenced examples” was [13][14], but it might help you to know that my initial comment to this was the following: Use my confusion about it if you like
    • What referenced examples? Either i missed them, or you havn’t clearly pointed to the examples in you article, or there should be a link to a more elaborate description of the example which resulted in the idle developers
• One last thing is that I would recommend you to improve the use of the two figures.
  • Firstly, you should include legends so the reader knows what each line (and blue area) represents
  • Secondly i suggest to explain the meaning of what the pictures show a little more than you have done now