Talk:Story Points Estimation

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.

Username: 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

Username: s143352, Reviewer #2

• The article is written in a good and accurate manner and the reader is well guided through the different sections.
• The Topic is very relevant in both project, program and… portfolio management.
• The academic level and quality of the content, seems to me to be quite good.
• Good idea to implement the method in practical use, gives the reader a better grasp of the context.

Username: s146898, Reviewer #3

Hey :) I like your topic and I think you've done a good job with the article. There are only minor things that I will address in the form of bullet-points below.

Formal aspects

• The article follows the Methods structure
• Apart from minor mistakes that you will probably correct when proofreading, the article has good grammar and spelling.
• Regarding the figures, I believe they should be numbered e.g. “Figure 1 -….” And they should also have a legend. I would also suggest to include a figure that illustrates the 6 steps and another one for the comparison you make between the alternatives. It would just make things easier to grasp.
• I really like that your article links to other wiki pages

Content aspects

• I think it would provide a practitioner with a good understanding of how to use Story points
• The article seems to have the appropriate length and it relates to the course
• I really liked your summary and I think it’s a good introduction
• The references you list seem relevant and trustworthy. Don’t forget, however, about the annotated bibliography
• It’s nice that you used categories for the article.

Reaction to Feedback

User s113735:

Response will be given in the format:

• Copy of the first Suggestion/Comment:

- Response from s113735...

• Copy of

- Response from s113735...

Response to user MistaJacob

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

-Figures (2 and 3) are placed as intended because they relate to a broader aspect of the article rather than just the "benefits" part. The list of "all 1's" have been fixed and now displays properly with added subheadings etc.

• Maybe consider sub-headings instead of bold under the section of Alternatives.

-Added for easier understanding/navigation.

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

-Proof read and corrected.

• Remember to make the annotated bibliography

-Annotated bibliography has been added at the end of the article, before the reference list.

• I found the article relevant, with a good red thread through it. The length seems appropriate to what you want to convey.

-Thank you :)

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

-I have added ~4 lines in the introduction that includes an example of a "User Story". I also specify more clearly the purpose and use of the tool and that it isn't an obvious choice for non-agile project teams.

• 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 deleted "the individual" because it was noise.

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

-I have addressed this with the added 4 lines in the introduction.

• 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

-Thank you :)

• 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?

-Also addressed in the 4 lines in the introduction.

• 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)

-I have linked to your Wiki about cognitive biases. I can see you have a reference to Kahneman, a renowned scholar about the topic. If you're reading this feedback I suggest finding his book "Thinking Fast and Slow" - it is a really great read, where he introduces the reader to the "two ways of thinking" that you also reference. The book has a lot of great analogies, mini-tests and examples of different ways of thinking.

• 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

-I have linked the article, although it provides no additional information to my topic (yet).

• 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

-Yes it could :) I have chosen to let it stay "as-is" because it argues slightly different points: "People are mad at estimating": Don't trust your estimations, and "Estimations are log-normally distributed": People are generally over-optimistic. I have done some slight reformatting to enhance this point.

• 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

-I have moved the references to the actual sentence "the referenced examples<ref><ref>". I have also added a pointer towards the annotated bibliography that I didn't have before.

• 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

-Legend now included in Figure text.

• • Secondly i suggest to explain the meaning of what the pictures show a little more than you have done now

-Naming, format and explanation added to all figures.

Response to user s143352

• The article is written in a good and accurate manner and the reader is well guided through the different sections.
• The Topic is very relevant in both project, program and… portfolio management.
• The academic level and quality of the content, seems to me to be quite good.
• Good idea to implement the method in practical use, gives the reader a better grasp of the context.

-Thank you for your feedback:)

Response to user s146898

Formal aspects

• The article follows the Methods structure
• Apart from minor mistakes that you will probably correct when proofreading, the article has good grammar and spelling.

-Proof read and corrected.

• Regarding the figures, I believe they should be numbered e.g. “Figure 1 -….” And they should also have a legend. I would also suggest to include a figure that illustrates the 6 steps and another one for the comparison you make between the alternatives. It would just make things easier to grasp.

-Figures have now been enumerated, referenced and explained better. Good idea with a Figure overview with the six phases of story-point estimations. I have made a quick mockup of the model and added it as a figure to the section.

• I really like that your article links to other wiki pages

-Thank you :)

Content aspects

• I think it would provide a practitioner with a good understanding of how to use Story points
• The article seems to have the appropriate length and it relates to the course
• I really liked your summary and I think it’s a good introduction
• The references you list seem relevant and trustworthy. Don’t forget, however, about the annotated bibliography

-Annotated bibliography has been added in front of the reference list.

• It’s nice that you used categories for the article.