Talk:Scrum Methodology in Agile Software Development
Contents |
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! :)
Answer to reviewer 1
Hi 113129, first of all thank you for your review and your advices.
- For the first two bullets yes I know that my English is not so academic but I’m trying to improve it . I’ll follow your suggestion on writing shorter sentences.
- Thank you for the references I wasn’t able to find the wiki code to write them in a more compact way. Now they are better.
- I think that the importance of Scrum methodology and ASD in project management is well dealt along the article. As it is written in the abstract the main innovation of ASD is to cope with customers’ needs that in the actual market are continuously changing. This is helpful to PM because traditional ways of managing projects can’t work well in this context.
Scrum Methodology:
- This is only an introduction sentence so I wanted to give just some informations of how Scrum works. Furthermore Scrum is not a deterministic method, but it is more experience driven. It is difficult to go more in details without a real project. In this article I just limited to describe how method works.
Manifesto ASD
- You are right I forgot it thank you
Application:
- Previous model were characterized by people who just followed their tasks step by step. Focusing on communication means that people start to work together giving a lower importance to the model structure that should be followed. In this way they are able to face difficulties that with the other ways of developing would involve problems.
- To facilitate communication team members should stay in a close location like a room for example. This help to isolate the team from the outside problem so that they can really focus on software development with more success.
- In the literature it is written that group has to be composed by minimum three and maximum nine. This because three members ensure that at least there are the basic skills necessary to develop a software (they cannot be enclosed in only one person). Nine members are considered the limit because communication tends to decrease with the increasing of people in the team. From the experience it was noticed that seven people are a trade-off between communication and cross-functionality of the members of the group.
- Yes you are right Sprint is explained in a following section, I put an internal link to connect them.
Main figures in Scrum
- Customer-centric items are that piece of project or work in which the Product Backlog is divided. You can consider them like an ordinary sequence of milestones to reach in order to complete the project. They are called Customer-centric to underline that differently from previous way of developing software, ASD has a particular focus on customer. In fact this items are decided during the Sprint Planning meeting in collaboration with customers.
Sprint Planning Meeting
- It was a mistake thank you
- You are right I forgot them. Now it should be ok
- I reviewed this section in order to correct some grammatical mistakes. I hope it is better now.
Artefacts
- I have put an Image of a Product Backlog in which you can read some example of PBIs.
- I have added some more details in the burndown chart.
Limitations
- I have corrected the mistake
- Unfortunately in the literature there is no so many information about use limitations of Scrum. This because Scrum is developed as an empirical method so it difficult to establish first in it is suitable or not to a project.
Yes I realized that the article flow is a little confuse, I tried to improve its clarity by adding some external link to Wikipedia referred to Software development models and by move some section in order to have a more orderly flow.
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
Answer to reviewer 3
Hi Jane, thank you for your review and your advices.
Formal Aspect
- You are right about the pictures. I have put some new images with a better resolution, if you open them, they will be clearer.
Content Aspect
- Yes, I know that Limitations section is not so wide, but literature doesn’t provide so many informations about this argument. I think because of the “empirical” way of Scrum to manage projects.
- In my references I put a link in which you can find all the information you need about Scrum Reference Card. It is its “official web site” so I think that it could help you.
- Unfortunately there are not deterministic tools in Scrum methodology to identify if a project is suitable to be developed with this method. Usually mangers are led by their own experience in order to define if a project is suitable to ASD.
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
Answer to reviwer 2
Hi Dimitris,thank you for your review and your advices.
Abstract:
- I corrected some mistake in the abstract and added some external links to Wikipedia to be clearer.
Scrum methodology
- I added the reference about the Scrum definition.
- Thank you for the suggestion
Application
- I have reformulated this section: now there Is a description of the Scrum Framework with some explanation of the Sprint and other things that will be explained later in the article. In this way I think that the article is more connected.
- Thank you for your suggestion “actors” is better.
Main figures in Scrum
- I think that it is better to keep the sections disconnected. In a normal article I would follow your advice but I think that in a Wiki article it is important to divide into different sections each topic.
Team self-organization
- It was “hamper” thank you
- I put the reference thank you
Scrum Meetings
- Yes I forgot the references in the pictures, now it is ok;
Sprint
- I wrote some more explanation of Sprint in the Application section. Now I think it is simpler to follow the article flow.
- In the references there is a link to the “official” site of Scrum reference Card, here you can download it.
