View source for Talk:Scrum Methodology in Agile Software Development

== 113129's comments: ==
General thoughts:
* Your language varies greatly; sometimes it is very simple, other times very advanced. You need to work on this – maybe use Microsoft Word when writing the article? Word will make grammatical suggestions (and corrections) if needed.
* You often make very long sentences. I’m personally not very good at using commas (I use them way too much, hehe!) but I think that if you maybe insert a few commas in your long sentences, then it will be easier for the reader to understand :)
* You make several references for the same book or website, but you can actually use one reference more than once! You can find a link on how to do that on the frontpage! (Can't put an example in here, sadly!) By doing this, you wont have the same website listed 5 times, but will just reference the same number more than once! :)
* Maybe make it clearer why Scrum and ASD is important for project/program/portfolio managers. 
* Please note, that I have not worked with Scrum myself, so I have no experience with this topic. I can mostly help you with general explanations, language and the like.
Abstract: 
* You start the article with an interesting perspective, however the choice of language varies greatly between the two sections. 
Scrum Methodology: 
* Maybe explain in more detail what the quote “work is divided into small chunks to manage complexity and to get early feedback from customers and end users” means. You only use this quote and the following sentence to explain the scrum methodology. I don’t feel like I fully understood the scrum methodology after reading this.

Manifesto of Agile Software Development:
* Remember to put a reference to the quote “Welcome changing requirements, even late in development” (http://agilemanifesto.org/principles.html)
* Good and interesting section! 

Application:
* I do not understand how, by focusing on communication, the team is able to make decisions quicker and respond faster. Why are they even focusing on communication in the first place?
* What does it mean to work “in close location”?
* Does the team always consist of seven people? That is an odd group number – why seven?
* I feel like I understand the roles within the Scrum framework now, but I do not understand the “sprints”. Are they “just” timeframes within the project? You keep mentioning them, but you haven’t explained them yet.
* You answer some of these questions later in the article, but it does not feel like there is a natural flow. When introducing a new concept, I suggest you should explain it shortly afterwards. I feel like you mentioned and used some concepts before explaining what they meant, which I found very confusing. 

Main Figures in Scrum:
* What are customer-centric items?

Sprint: 
* Really good! This one cleared up a lot. It was short and concrete. I liked it.

Scrum Meetings:
* The text is italic in the end of the first section (sprint planning meeting).
* Remember to reference the figure! :)
* These are some good sections. They are informative and easy to understand, however there are a few grammatical errors and a few words missing once in a while.

Artefacts:
* Maybe make an example of a PBI or of what a product backlog could include? ☺
* Maybe explain the Sprint Burndown Chart a bit more – use the picture for examples.

Limitations:
* “because” not “cause” ;) 
* This sections is called limitations, but you seem to only refer to M. James’ limitation condition, in stead of discussion it. Maybe you could bring forward a few examples when scrum is used and when it is not? :) 

All in all: I liked the article. At times it was a little confusing, and the order of the sections was a little confusing as well. However it was informative and covered a lot of knowledge about Scrum. Maybe work a bit on your language, make a few examples and remember to put references on pictures. Maybe also refer to other wiki-articles on the website, to direct the reader towards similar articles (about the same topic!)

// This concludes 113129's comments! :)
----
Reviewer 3, S997303

Hi Giacomo

Formal aspects

•	Interesting methodology and your writing style is clear and fluent to me

•	You use appropriate figures, but consider making them larger, so they become less blurred. Especially I suggest making the Scrum Framework figure larger in scale, because this is the visual overview of the Scrum Methodology in your article.

•	Also it could be an advantage to enlarge the Product Backlog figure as well as the Sprint Backlog so they can better visualize and support your text.

Content aspects

•	If I look at the balance of the sections in your article I could suggest to focus more on the limitations section and for example supporting your facts with additional literature about use of Scrum methodology in software development.

•	Your article is very detailed described for a practitioner – and if I was a practitioner I would also be very interested in knowing more about the Scrum Reference Card and how to evaluate when a project belongs in the chaotic field of the Predictability figure and therefore should select a Scrum Methodology.

Good luck with the completion of your article. 
Best Regards Jane
----


'''Reviewer 2, Dimak'''

Hi,

I found your article very interesting with a lot of information about Scrum methodology and a lot of illustrations. Expect from some points the referencing was good. As far as the structure and the language are concerned, I believe that there are some improvements that can be made and thus I will give some examples by commenting each section of your article.

'''Abstract'''

You have a nice abstract and you nicely analyze what is the purpose of your article but there are some points that in my opinion you should focus on improving. More specifically:

• Customer’s and market’s needs can be reformulated to customers' and markets' needs.
• When you first mention Agile Software Development, you can write (ASD) in brackets so that you will not have to use it as a whole again
• In general I believe that you can revise a bit your syntax in some sentences. Also you can try to keep them a bit shorter. I always use big sentences myself so I definitely cannot judge you for that!  
• You can use http://www.thesaurus.com/ to find some expressions or synonyms for your article. Personally it helped me a lot ;)

'''Scrum Methodology'''

• In the point you say about rugby -which by the way find very interesting as a connection, you can maybe use a reference.
• Not only in this section, but also in the whole article, it will be more easier for someone to follow if you use connectors (e.g. Furthermore, Moreover etc.)

'''Agile Software Development'''

There are some really nice points here but again a bit of reformulation is needed. I like that you use bullet-points.

'''Manifesto for the Agile Software development'''

Just a small suggestion. You can write seventeen instead of 17 to make your article a bit more formal 

'''Application'''

Again I believe that there are some points that you can reformulate to make it easier for a practitioner to follow. I like the contents you have in this section. 

• You can write a few words as a small introduction and as a connection to the previous section.
• Maybe you can connect the illustration about scrum framework to the text because for me, the connection is a bit unclear.
• Just a small suggestion. Maybe you can write actors instead of figures.

'''Main figures in Scrum'''

I got a little confused in this section because I thought that you talked about the figures earlier. Maybe you can consider a way to connect these two sections. For instance, when you mention them for the first time you can write : "these figures will be further analyzed in a following section" or something like that.

• Maybe you can use a bit more references when you talk about the Product Owner, the Development team and the Scrum Master.
• Here you mention some artefacts that are used in Scrum methodology. Maybe it will be better to analyze them here and not on another part because I believe it can be more difficult for a practitioner to follow. For instance, when I first read your article I was not sure on what a product backlog is until I found it below and I went back to make the connection. This bullet point covers the '''Artefacts''' section as well.

'''Team self-organization'''

Again I like that you have bullet points. It makes it easier for someone to follow. 

• At some point you say “it is told developer what needs to be done not how to do it”. Maybe you can use a reference on that.
• You say: "Conversely there are some conditions that can hander self-organization". Maybe you meant harden instead of hander.

'''Scrum Meetings'''

Nice points here as well. There are still some grammatical and syntax errors I think you should check. 

• Remember to use a reference for your illustration.

'''Sprint'''

This section is cohesive and straight forward but as a minor suggestion I believe that you could have explained it a bit earlier when you talk about Sprints in the Application section.

'''Limitations'''

Maybe you can use an image to illustrate the scrum reference card.

I hoped that I helped you by giving these suggestions and I wish you good luck with your final article.

Dimitris