Revision as of 12:55, 24 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.

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.

-

• 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

-Annotated bibliography has been added by the end.

• 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

-