DTU ProjectLab - User contributions [en-gb]

Scrum Methodology in Agile Software Development

2015-09-28T22:06:33Z

S150821: /* Team self-organization */

Today market is affected by uncertainly and sudden changes, in these conditions most of the models used in the 20th century to develop software are not still appropriate.[[Wikipedia:Waterfall model | Waterfall model]] , probably the most famous between them, is characterized by a stiff structure which can’t cope with the turbulent needs of the actual market.
In recent years many innovations are been enhanced in software engineering with a particular focus on the flexibility of these methods in order to cope with the customers' and markets' needs; surely [[Wikipedia: Agile Software Development |Agile Software Development (ASD)]] is between them.

ASD embraces the principles of [[Wikipedia:Lean Production|Lean Production]] by applying them in software development to avoid waste and increase responsiveness to change. It represents the solution to the unpredictability of the market where the capacity "to welcome change even late in development" (''K. Beck et all, 2001'')<ref name='Manifesto'></ref> is required.
This article deals with Agile Software Development with a particular focus on one of its most used technique : '''Scrum Methodology'''.

=Scrum Methodology=
Scrum is an iterative method used to develop software, it can be placed inside the group of methods which are used in '''ASD'''. This word is taken from rugby and represents that phase of the match where an ordered formation of players, with arms interlocked and heads down, push forward against a similar group to gain possession of the ball<ref name='Cohen'></ref>. This method provides that "work is divided into small chunks to manage complexity and to get early feedback from customers and end users" (''S. Augustine, 2005'')<ref>S. Augustine,2005,Prentice Hall PTR,Managing Agile Projects</ref>; software development is carried out by small working team that allow rapid adjustment during the process and a quick delivery of the final product.

==Agile Software Development==
At the end of the 20th century there were some practitioners who believed that traditional [[Wikipedia:Iterative model |Iterative model]] was not so responsive to market changes. They defined Agile a process which was able to accept change rather than stress predictability.They also believed that to well face customers’ needs development software methods have to respond to change as quickly as it arose rather than prevent changes.<ref name='Cohen'>D.Cohen,M.Lindval,P. Costa,Fraunhofer Center Maryland, Agile Software Development</ref>

It was in these circumstances that practitioners as Mary Poppendieck and Bob Charet started to take inspiration from Lean manufacturing principles and apply them to software development.
These are the main points ,according to Poppendieck, which make Lean Production so successful and that can be applied to software development:

*elimination of waste that does not add value to the customer such as diagram and models that do not add value to the final deliverable;
*minimize inventory such as requirements and design documents;
*maximize flow by using iterative development to reduce development time;
*pull from demand;
*empower workers that means “tell developer what needs to be done not how to do it";
*meet customer requirements – work closely with the customer, allowing them to change their minds
*do it right the first time – test early and refactor when necessary;
*abolish local optimization – flexibly manage scope;
*partner with suppliers – avoid adversarial relationships, work towards developing the best software;
*create a culture of continuous improvement – allow the process to improve, learn from mistakes and successes.<ref name='Cohen'></ref><ref>M. Poppendieck, T. Poppendieck, 2003, Addison Wesley, Lean Software Development: An Agile Toolkit[[http://www.poppendieck.com/]]</ref>

===Manifesto for the Agile Software development===
A few years before Poppoendieck’s publication, on February 2001,a group of seventeen software developers published in a work called “Manifesto for the Agile Software Development”<ref name='Manifesto'>K. Beck et al., 2001, Manifesto for Agile Software Development[http://www.agilemanifesto.org/]</ref> the main principles of Agile Software development.

From reading these few words it is possible to identify what are the main innovations that ASD introduced in Software development:
[[File:Agilemanifesto.jpg|400px|thumb|right|Manifesto for the Agile Software development<ref name='Manifesto'></ref>]]

*'''“Individuals and interactions”''': with these words founders want to remark the power of human being creativity and also the ability of each man to collaborate with his other similar. The stiffness of Waterfall model is instead represented by “processes and tools” where people was used to follow only what the plan required.
*'''“Working software“''': here there is a clear reference to the new way of developing software where at every iteration a working program is realised. This is different from the previous model in which a working program couldn’t be seen until the end of the project. This feature is put over the “comprehensive documentation” which characterizes especially Waterfall model.
*'''“Customer collaboration”''': it means that there must be a straight relationship between customer and developer in order to define time by time the projects requirements and evaluate every realise.
*'''“Responding to change over following a plan”''': this sentence encloses the essence of Agile software Development that is to cope with turbulent markets by being flexible and by responding quickly to change. This concept was remarked by the founders in one of the twelve principles which follow the manifesto which says “Welcome changing requirements, even late in development […]”.<ref name='Manifesto'></ref>

=Application=
[[File:Scrum_Framework.png|350px|thumb|right|Scrum Framework]]
There are two concepts that are at the basement of Scrum methodology: '''iterative development''' and '''team working'''. Developing in iterations allow Scrum team to adapt quickly to changing requirements, while working in close location and focusing on communication allow team to make decisions and act on them immediately rather than wait on correspondence.<ref name='Cohen'></ref>

Basically Scrum consists in a sequence of fixed-length iterations called '''Sprint''' that are the fundamental units in which the whole project is divided. As the picture shows Scrum framework is really simple: it starts from a vision like all projects. This idea is converted into a plan during the preliminary meetings where customers and developers identifies the main software requirements and defines the Product Backlog. This represents the entire amount of work that has to be done in order to develop the software. In the next step Product Backlog is divided into several Sprint Backlogs that define which tasks have to be done during the following Sprint. During these iterations the product experiences an incremental development at the end of which it is potentially shippable.

Every Sprint is managed by one or more '''cross-functional and self-organizing teams''' each composed by seven people. There are also other two actors whose task is to be supportive of the software development. One is the '''Product Owner''' who mainly handles customers' contacts, and the other is the '''Scrum Master''' whose main task is to ensure that development team can work without obstacles.

Each sprint usually lasts from 2 to 4 weeks, in this period there are at least one meeting between the Product Owner and Development Team in order to define the main objectives; then there are also short daily meetings held every morning to enhance communication, inform customers, developers, and managers on the status of the project, identify any problems encountered, and keep the entire team focused on a common goal.<ref name='Cohen'></ref>

==Main Actors in Scrum==
===Product Owner===
Product owner is the link between customers and development team, he ensures that deliverables are in line with customers’ expectation and that stakeholders’ interests are fulfilled. He has also the task to fill out customer-centric items (typically '''user stories'''), ranks and prioritizes them before adds them to the '''Product Backlog'''.

Usually development teams have only one Product owner, but differently from the Scrum master, he only takes care of the business side and does not interfere with the scrum team about the technological issues. At the beginning of each Sprint the Product Owner holds a Sprint Planning Meeting to state on which Product Backlog Items Scrum team will go to work during the next Sprint. In this phase he defines what are the most important items for that business, in according to the customer’s needs.

===Development Team===
Development team task is to deliver Product Backlog Items (PBIs) at the end of every Sprint in according with customers’ requirements.
Usually each team is composed by '''cross-functional members''' that allow an all-round software development; the main figures that there must be are a mix of software engineers, architects, programmers, analysts, QA experts, testers, and UI designers.

The size of the team is an important point, the group members' number influences capacity of people to communicate and work together: it is recommended that a scrum team is composed not more than nine people, usually seven.

Another peculiarity of Scrum team is its Self-organization which facilitates members’ creativity and increases team cohesiveness. For this reason it is recommended to not change the members of a team after they have worked together, especially if they had success in their project. After working together team members gain a mutual understanding that increases their capacity of team working, this synergy cannot be acquired if team are continuously changed.

A further point that characterized the good outcomes of a scrum team is location: people are most successful when located in the same room, particularly for the first few Sprints, this facilitates communication and information sharing.

====Team self-organization====
Team self-organization is a crucial point in the scrum methodology. This new concept is well explained in the sentence “it is told developer what needs to be done not how to do it”<ref name='Cohen'></ref>. It means that they can autonomously choose the way to reach commitments.
Furthermore, as it is explained previously, during Sprint execution team members develop an intrinsic interest in shared goals, in this way self-organizing teams can radically outperform larger than traditionally managed teams. It has to be specified that an optimal self-organization takes time: it may be possible that for the first few sprints developers perform worse than when they work in the traditional way.

Some requirements are necessary to gain a good team self-organization:
*members are committed to clear, short-term goals;
*members can gauge the group’s progress;
*members can observe each other’s contribution;
*members feel safe to give each other unvarnished feedback.<ref name='James'>M. James,2010,Scrum Reference Card[[http://scrumreferencecard.com/]]</ref>

Conversely there are some conditions that can hamper self-organization:
*geographical distribution: it is better if the whole team work in a room;
*boss/work dynamics: each member has to consider the others as peer to facilitate a fair communication between them;
*part-time team members;
*interruptions unrelated to Sprint goals.

===Scrum Master===
The scrum master worries that Scrum team can work without obstacles but he has no management authority over them. Essentially he has the aim to:
*create an environment to promote team self-organization;
*support team in the achievement of expected goals;
*ensure that events (e.g. daily Scrum meeting) take place in the right way;
*keep '''Scrum artefacts''' visible ('''Product Backlog''', '''Sprint Backlog''', '''Sprint burndown chart''' …).

==Sprint==
As it is already explained before Sprint (or iteration) is the fundamental unit in which the whole project is divided. It is characterized by a fixed length of 2 weeks or 30 days and by a goal to achieve. At the beginning of each sprint Scrum team , Product Owner , Scrum Master and sometimes also stakeholders hold a meeting, called Sprint Planning meeting. During this encounter it is defined the Sprint Backlog which states what are the goals and requirements of the next Sprint. After this, further meetings inside development team will be held in order to define in more detail how achieving the common goals stated in the previous meetings.

==Scrum Meetings==
[[File:Scrum_meetings.png|350px|thumb|right|Scrum Meetings<ref name='James'></ref>]]
Meetings are the fundamental tool used during the whole Scrum process. Usually they are facilitated by the Scrum master who however has no decision-making authority over them. There are different typologies of meetings according to the different phase of the process in which we are.
===Sprint Planning Meeting===
At the beginning of each Sprint, the Product Owner and team hold a Sprint Planning Meeting to define on which '''Product Backlog Items (PBIs)''' they will go to work during the next Sprint. During this meeting "The Product Owner is responsible for declaring which items are the most important to the business" instead "the team is responsible for selecting the amount of work they feel they can implement" (''M. James, 2010'')<ref name='James'></ref>.In this phase in perfect Lean perspective Scrum team “pulls” work from the Product Backlog to the Sprint Backlog. At the end of the meeting the selected items are broken into a provisional list of Sprint task. The maximum time that can be used to do Planning meeting, known as '''timebox''', is of eight hours.

===Daily Scrum and Sprint Execution===
During the sprint every day members of the Scrum team hold a fifteen minutes meeting where they take stock of the situation. Usually they speak about what they did the previous day, which impediments they faced and what they are going to do in the current day. To make these meetings shorter it is better that people are standing.
During sprint execution it is common to find out additional tasks necessary to achieve sprint goal; to keep the control over processes during sprint development it could be useful to maintain a current '''Sprint Task List''', a '''Sprint Burndown Chart''', and an '''Impediments List''': these are some artefacts that allow developer to understand where the project is located.

===Sprint Review Meeting===
At the end of every Sprint it is held a Review meeting where the scrum team has to explain to the Product Owner what they did during the previous sprint. Usually this meeting consists in a live demonstration of the working product increment after which Product Owner states which Items can be considered as done.
Items which are declared not done have to return to the Product Backlog to be ranked and reprioritized by the Product Owner with the help of the Scrum master. Last step of this meeting is to convert stakeholders’ feedback to a new Product Log, this task is consigned to both Product Owner and Scrum Master.
The Sprint Review Meeting is the appropriate meeting for external stakeholders (even end users) to attend.

===Sprint Retrospective Meeting===
During this meeting every member of the scrum team inspects his behaviour to identify some impediments that he faced during the Sprint. There are mainly three kind of impediments in which developers can be involved:
*people who conduct performance evaluation are an obstacles to transparency of the team;
*human tendency of someone in the team to jump to conclusions and propose actions too quickly;
*geographical distribution of the team can be an impediments, team work better if they are delimited in a small place like a room.<ref name='James'></ref>

After identifying all these impediments Scrum master has the task to eliminate them.

===Backlog Refinement Meeting ===
Especially at the beginning of the project "most of the Product Backlog Items (PBIs) need refinement because they are too large and poorly understood" (''M. James, 2010'')<ref name='James'></ref>. In the Backlog Refinement Meeting, the gives an estimation of the remaining work that is required to complete the Items in the Product Backlog and provides other technical informations in order to help the Product Owner to prioritize them.

==Artefacts==
[[File:Product_Backlog_2.png|350px|thumb|right|Product Backlog and Sprint Backlog<ref name='James'></ref>]]
===Product Backlog===

It is defined before the project beginning and then upgraded during the Backlog Refinement meeting ; it is made up by the whole group of items which have to be completed during the project in order to realize the final product. Every item is ranked and constantly reprioritized by the Product Owner. It is important that Product Backlog is visible to the stakeholders.

===Product Backlog Item (PBI)===
An item specifies what has to be done but not how do it. Usually they are written in a User story to be understood also by stakeholders. Every items has a work load of 2-3 days and requires 2-3 people. It represents the basic unit of the Product backlog.
[[File:Sprint_Backlog.png|200px|thumb|right|Sprint Backlog<ref name='James'></ref>]]
===Sprint backlog===

It is defined at the beginning of each sprint during the Sprint Planning meeting where the committed items and the main task that have to be done during the sprint are identified. It has to be visible to the Scrum team and also upgraded during the sprint execution with the additional tasks necessary to achieve the final goal.

===Sprint task===
Every item is divided into several tasks, each of them requires one day or less of work. A sprint task specifies how to achieve what is required by PBI. If the task takes more than one day of work, remaining effort is re-estimated daily, typically in hours.

===Sprint Burndown Chart===
[[File:Sprint_burndown_chart.png|300px|thumb|right|Sprint Burndown Chart<ref name='James'></ref>]]
This tool is used to facilitate self-organization of the team. It indicates the total remaining team task hours within one Sprint. Usually chart shows a decreasing line but if there are some re-estimation it may be possible that line increase for then going down. As picture shows it has a time line in the x axis and the remaining hours of work within one Sprint in the y axis. The advantage of this tool is to show at a first sight at which point of the project you are and the work that is left to complete the Sprint. It is important that this tool is used only as help to Scrum team; in some situations it could become a constraint for developers, in this case Scrum Master has to remove this chart from the room.

=Limitations=
Scrum method was often used in the object-oriented software development. Actually this technique are applied not only on software but also on other products from different sectors like wheelchairs, semiconductors and mortgages.
Scrum has to be used in those projects where people cannot rely on the plan-driven approaches like Waterfall, because of unknown requirements and technology.
[[File:Graph.png|300px|thumb|right|Predictability of a Project<ref name='James'></ref>]]
Conversely if the projects is placed under precise and stable conditions it is better to use one of the traditional model which allow to have a fixed planning over the whole project. In this case Scrum method would involve in a waste of resources and money because he is working on a field that is not its responsibility.

Michael James in his “Scrum Reference card” explains with a simple graphics in which conditions Scrum should be used and which ones are not. James defines the predictability of the projects on the base of two features: knowledge of the requirements and knowledge of the level of technology required. A project which provides known requirements and a known level of technology should be carried out with a plan-driven model. It these conditions are not met it is better to use an empirical approach like Scrum.<ref name='James'></ref>

=References=
<references/>

Scrum Methodology in Agile Software Development

2015-09-28T22:01:38Z

S150821: /* Application */

Today market is affected by uncertainly and sudden changes, in these conditions most of the models used in the 20th century to develop software are not still appropriate.[[Wikipedia:Waterfall model | Waterfall model]] , probably the most famous between them, is characterized by a stiff structure which can’t cope with the turbulent needs of the actual market.
In recent years many innovations are been enhanced in software engineering with a particular focus on the flexibility of these methods in order to cope with the customers' and markets' needs; surely [[Wikipedia: Agile Software Development |Agile Software Development (ASD)]] is between them.

ASD embraces the principles of [[Wikipedia:Lean Production|Lean Production]] by applying them in software development to avoid waste and increase responsiveness to change. It represents the solution to the unpredictability of the market where the capacity "to welcome change even late in development" (''K. Beck et all, 2001'')<ref name='Manifesto'></ref> is required.
This article deals with Agile Software Development with a particular focus on one of its most used technique : '''Scrum Methodology'''.

=Scrum Methodology=
Scrum is an iterative method used to develop software, it can be placed inside the group of methods which are used in '''ASD'''. This word is taken from rugby and represents that phase of the match where an ordered formation of players, with arms interlocked and heads down, push forward against a similar group to gain possession of the ball<ref name='Cohen'></ref>. This method provides that "work is divided into small chunks to manage complexity and to get early feedback from customers and end users" (''S. Augustine, 2005'')<ref>S. Augustine,2005,Prentice Hall PTR,Managing Agile Projects</ref>; software development is carried out by small working team that allow rapid adjustment during the process and a quick delivery of the final product.

==Agile Software Development==
At the end of the 20th century there were some practitioners who believed that traditional [[Wikipedia:Iterative model |Iterative model]] was not so responsive to market changes. They defined Agile a process which was able to accept change rather than stress predictability.They also believed that to well face customers’ needs development software methods have to respond to change as quickly as it arose rather than prevent changes.<ref name='Cohen'>D.Cohen,M.Lindval,P. Costa,Fraunhofer Center Maryland, Agile Software Development</ref>

It was in these circumstances that practitioners as Mary Poppendieck and Bob Charet started to take inspiration from Lean manufacturing principles and apply them to software development.
These are the main points ,according to Poppendieck, which make Lean Production so successful and that can be applied to software development:

*elimination of waste that does not add value to the customer such as diagram and models that do not add value to the final deliverable;
*minimize inventory such as requirements and design documents;
*maximize flow by using iterative development to reduce development time;
*pull from demand;
*empower workers that means “tell developer what needs to be done not how to do it";
*meet customer requirements – work closely with the customer, allowing them to change their minds
*do it right the first time – test early and refactor when necessary;
*abolish local optimization – flexibly manage scope;
*partner with suppliers – avoid adversarial relationships, work towards developing the best software;
*create a culture of continuous improvement – allow the process to improve, learn from mistakes and successes.<ref name='Cohen'></ref><ref>M. Poppendieck, T. Poppendieck, 2003, Addison Wesley, Lean Software Development: An Agile Toolkit[[http://www.poppendieck.com/]]</ref>

===Manifesto for the Agile Software development===
A few years before Poppoendieck’s publication, on February 2001,a group of seventeen software developers published in a work called “Manifesto for the Agile Software Development”<ref name='Manifesto'>K. Beck et al., 2001, Manifesto for Agile Software Development[http://www.agilemanifesto.org/]</ref> the main principles of Agile Software development.

From reading these few words it is possible to identify what are the main innovations that ASD introduced in Software development:
[[File:Agilemanifesto.jpg|400px|thumb|right|Manifesto for the Agile Software development<ref name='Manifesto'></ref>]]

*'''“Individuals and interactions”''': with these words founders want to remark the power of human being creativity and also the ability of each man to collaborate with his other similar. The stiffness of Waterfall model is instead represented by “processes and tools” where people was used to follow only what the plan required.
*'''“Working software“''': here there is a clear reference to the new way of developing software where at every iteration a working program is realised. This is different from the previous model in which a working program couldn’t be seen until the end of the project. This feature is put over the “comprehensive documentation” which characterizes especially Waterfall model.
*'''“Customer collaboration”''': it means that there must be a straight relationship between customer and developer in order to define time by time the projects requirements and evaluate every realise.
*'''“Responding to change over following a plan”''': this sentence encloses the essence of Agile software Development that is to cope with turbulent markets by being flexible and by responding quickly to change. This concept was remarked by the founders in one of the twelve principles which follow the manifesto which says “Welcome changing requirements, even late in development […]”.<ref name='Manifesto'></ref>

=Application=
[[File:Scrum_Framework.png|350px|thumb|right|Scrum Framework]]
There are two concepts that are at the basement of Scrum methodology: '''iterative development''' and '''team working'''. Developing in iterations allow Scrum team to adapt quickly to changing requirements, while working in close location and focusing on communication allow team to make decisions and act on them immediately rather than wait on correspondence.<ref name='Cohen'></ref>

Basically Scrum consists in a sequence of fixed-length iterations called '''Sprint''' that are the fundamental units in which the whole project is divided. As the picture shows Scrum framework is really simple: it starts from a vision like all projects. This idea is converted into a plan during the preliminary meetings where customers and developers identifies the main software requirements and defines the Product Backlog. This represents the entire amount of work that has to be done in order to develop the software. In the next step Product Backlog is divided into several Sprint Backlogs that define which tasks have to be done during the following Sprint. During these iterations the product experiences an incremental development at the end of which it is potentially shippable.

Every Sprint is managed by one or more '''cross-functional and self-organizing teams''' each composed by seven people. There are also other two actors whose task is to be supportive of the software development. One is the '''Product Owner''' who mainly handles customers' contacts, and the other is the '''Scrum Master''' whose main task is to ensure that development team can work without obstacles.

Each sprint usually lasts from 2 to 4 weeks, in this period there are at least one meeting between the Product Owner and Development Team in order to define the main objectives; then there are also short daily meetings held every morning to enhance communication, inform customers, developers, and managers on the status of the project, identify any problems encountered, and keep the entire team focused on a common goal.<ref name='Cohen'></ref>

==Main Actors in Scrum==
===Product Owner===
Product owner is the link between customers and development team, he ensures that deliverables are in line with customers’ expectation and that stakeholders’ interests are fulfilled. He has also the task to fill out customer-centric items (typically '''user stories'''), ranks and prioritizes them before adds them to the '''Product Backlog'''.

Usually development teams have only one Product owner, but differently from the Scrum master, he only takes care of the business side and does not interfere with the scrum team about the technological issues. At the beginning of each Sprint the Product Owner holds a Sprint Planning Meeting to state on which Product Backlog Items Scrum team will go to work during the next Sprint. In this phase he defines what are the most important items for that business, in according to the customer’s needs.

===Development Team===
Development team task is to deliver Product Backlog Items (PBIs) at the end of every Sprint in according with customers’ requirements.
Usually each team is composed by '''cross-functional members''' that allow an all-round software development; the main figures that there must be are a mix of software engineers, architects, programmers, analysts, QA experts, testers, and UI designers.

The size of the team is an important point, the group members' number influences capacity of people to communicate and work together: it is recommended that a scrum team is composed not more than nine people, usually seven.

Another peculiarity of Scrum team is its Self-organization which facilitates members’ creativity and increases team cohesiveness. For this reason it is recommended to not change the members of a team after they have worked together, especially if they had success in their project. After working together team members gain a mutual understanding that increases their capacity of team working, this synergy cannot be acquired if team are continuously changed.

A further point that characterized the good outcomes of a scrum team is location: people are most successful when located in the same room, particularly for the first few Sprints, this facilitates communication and information sharing.

====Team self-organization====
Team self-organization is a crucial point in the scrum methodology. This new concept is well explained in the sentence “it is told developer what needs to be done not how to do it”<ref name='Cohen'></ref>. It means that they can autonomously choose the way to reach commitments.
Furthermore, as it is explained previously, during Sprint execution team members develop an intrinsic interest in shared goals, in this way self-organizing teams can radically outperform larger than traditionally managed teams. It has to be specified that an optimal self-organization takes time: it may be possible that for the first few sprints developers perform worse than when they work in the traditional way.

Some requirements are necessary to gain a good team self-organization:
*members are committed to clear, short-term goals;
*members can gauge the group’s progress;
*members can observe each other’s contribution;
*members feel safe to give each other unvarnished feedback.<ref name='James'>M. James,2010,Scrum Reference Card, Michael James,[[http://scrumreferencecard.com/]]</ref>

Conversely there are some conditions that can hamper self-organization:
*geographical distribution: it is better if the whole team work in a room;
*boss/work dynamics: each member has to consider the others as peer to facilitate a fair communication between them;
*part-time team members;
*interruptions unrelated to Sprint goals.

===Scrum Master===
The scrum master worries that Scrum team can work without obstacles but he has no management authority over them. Essentially he has the aim to:
*create an environment to promote team self-organization;
*support team in the achievement of expected goals;
*ensure that events (e.g. daily Scrum meeting) take place in the right way;
*keep '''Scrum artefacts''' visible ('''Product Backlog''', '''Sprint Backlog''', '''Sprint burndown chart''' …).

==Sprint==
As it is already explained before Sprint (or iteration) is the fundamental unit in which the whole project is divided. It is characterized by a fixed length of 2 weeks or 30 days and by a goal to achieve. At the beginning of each sprint Scrum team , Product Owner , Scrum Master and sometimes also stakeholders hold a meeting, called Sprint Planning meeting. During this encounter it is defined the Sprint Backlog which states what are the goals and requirements of the next Sprint. After this, further meetings inside development team will be held in order to define in more detail how achieving the common goals stated in the previous meetings.

==Scrum Meetings==
[[File:Scrum_meetings.png|350px|thumb|right|Scrum Meetings<ref name='James'></ref>]]
Meetings are the fundamental tool used during the whole Scrum process. Usually they are facilitated by the Scrum master who however has no decision-making authority over them. There are different typologies of meetings according to the different phase of the process in which we are.
===Sprint Planning Meeting===
At the beginning of each Sprint, the Product Owner and team hold a Sprint Planning Meeting to define on which '''Product Backlog Items (PBIs)''' they will go to work during the next Sprint. During this meeting "The Product Owner is responsible for declaring which items are the most important to the business" instead "the team is responsible for selecting the amount of work they feel they can implement" (''M. James, 2010'')<ref name='James'></ref>.In this phase in perfect Lean perspective Scrum team “pulls” work from the Product Backlog to the Sprint Backlog. At the end of the meeting the selected items are broken into a provisional list of Sprint task. The maximum time that can be used to do Planning meeting, known as '''timebox''', is of eight hours.

===Daily Scrum and Sprint Execution===
During the sprint every day members of the Scrum team hold a fifteen minutes meeting where they take stock of the situation. Usually they speak about what they did the previous day, which impediments they faced and what they are going to do in the current day. To make these meetings shorter it is better that people are standing.
During sprint execution it is common to find out additional tasks necessary to achieve sprint goal; to keep the control over processes during sprint development it could be useful to maintain a current '''Sprint Task List''', a '''Sprint Burndown Chart''', and an '''Impediments List''': these are some artefacts that allow developer to understand where the project is located.

===Sprint Review Meeting===
At the end of every Sprint it is held a Review meeting where the scrum team has to explain to the Product Owner what they did during the previous sprint. Usually this meeting consists in a live demonstration of the working product increment after which Product Owner states which Items can be considered as done.
Items which are declared not done have to return to the Product Backlog to be ranked and reprioritized by the Product Owner with the help of the Scrum master. Last step of this meeting is to convert stakeholders’ feedback to a new Product Log, this task is consigned to both Product Owner and Scrum Master.
The Sprint Review Meeting is the appropriate meeting for external stakeholders (even end users) to attend.

===Sprint Retrospective Meeting===
During this meeting every member of the scrum team inspects his behaviour to identify some impediments that he faced during the Sprint. There are mainly three kind of impediments in which developers can be involved:
*people who conduct performance evaluation are an obstacles to transparency of the team;
*human tendency of someone in the team to jump to conclusions and propose actions too quickly;
*geographical distribution of the team can be an impediments, team work better if they are delimited in a small place like a room.<ref name='James'></ref>

After identifying all these impediments Scrum master has the task to eliminate them.

===Backlog Refinement Meeting ===
Especially at the beginning of the project "most of the Product Backlog Items (PBIs) need refinement because they are too large and poorly understood" (''M. James, 2010'')<ref name='James'></ref>. In the Backlog Refinement Meeting, the gives an estimation of the remaining work that is required to complete the Items in the Product Backlog and provides other technical informations in order to help the Product Owner to prioritize them.

==Artefacts==
[[File:Product_Backlog_2.png|350px|thumb|right|Product Backlog and Sprint Backlog<ref name='James'></ref>]]
===Product Backlog===

It is defined before the project beginning and then upgraded during the Backlog Refinement meeting ; it is made up by the whole group of items which have to be completed during the project in order to realize the final product. Every item is ranked and constantly reprioritized by the Product Owner. It is important that Product Backlog is visible to the stakeholders.

===Product Backlog Item (PBI)===
An item specifies what has to be done but not how do it. Usually they are written in a User story to be understood also by stakeholders. Every items has a work load of 2-3 days and requires 2-3 people. It represents the basic unit of the Product backlog.
[[File:Sprint_Backlog.png|200px|thumb|right|Sprint Backlog<ref name='James'></ref>]]
===Sprint backlog===

It is defined at the beginning of each sprint during the Sprint Planning meeting where the committed items and the main task that have to be done during the sprint are identified. It has to be visible to the Scrum team and also upgraded during the sprint execution with the additional tasks necessary to achieve the final goal.

===Sprint task===
Every item is divided into several tasks, each of them requires one day or less of work. A sprint task specifies how to achieve what is required by PBI. If the task takes more than one day of work, remaining effort is re-estimated daily, typically in hours.

===Sprint Burndown Chart===
[[File:Sprint_burndown_chart.png|300px|thumb|right|Sprint Burndown Chart<ref name='James'></ref>]]
This tool is used to facilitate self-organization of the team. It indicates the total remaining team task hours within one Sprint. Usually chart shows a decreasing line but if there are some re-estimation it may be possible that line increase for then going down. As picture shows it has a time line in the x axis and the remaining hours of work within one Sprint in the y axis. The advantage of this tool is to show at a first sight at which point of the project you are and the work that is left to complete the Sprint. It is important that this tool is used only as help to Scrum team; in some situations it could become a constraint for developers, in this case Scrum Master has to remove this chart from the room.

=Limitations=
Scrum method was often used in the object-oriented software development. Actually this technique are applied not only on software but also on other products from different sectors like wheelchairs, semiconductors and mortgages.
Scrum has to be used in those projects where people cannot rely on the plan-driven approaches like Waterfall, because of unknown requirements and technology.
[[File:Graph.png|300px|thumb|right|Predictability of a Project<ref name='James'></ref>]]
Conversely if the projects is placed under precise and stable conditions it is better to use one of the traditional model which allow to have a fixed planning over the whole project. In this case Scrum method would involve in a waste of resources and money because he is working on a field that is not its responsibility.

Michael James in his “Scrum Reference card” explains with a simple graphics in which conditions Scrum should be used and which ones are not. James defines the predictability of the projects on the base of two features: knowledge of the requirements and knowledge of the level of technology required. A project which provides known requirements and a known level of technology should be carried out with a plan-driven model. It these conditions are not met it is better to use an empirical approach like Scrum.<ref name='James'></ref>

=References=
<references/>

Scrum Methodology in Agile Software Development

2015-09-28T22:00:43Z

S150821: /* Manifesto for the Agile Software development */

Today market is affected by uncertainly and sudden changes, in these conditions most of the models used in the 20th century to develop software are not still appropriate.[[Wikipedia:Waterfall model | Waterfall model]] , probably the most famous between them, is characterized by a stiff structure which can’t cope with the turbulent needs of the actual market.
In recent years many innovations are been enhanced in software engineering with a particular focus on the flexibility of these methods in order to cope with the customers' and markets' needs; surely [[Wikipedia: Agile Software Development |Agile Software Development (ASD)]] is between them.

ASD embraces the principles of [[Wikipedia:Lean Production|Lean Production]] by applying them in software development to avoid waste and increase responsiveness to change. It represents the solution to the unpredictability of the market where the capacity "to welcome change even late in development" (''K. Beck et all, 2001'')<ref name='Manifesto'></ref> is required.
This article deals with Agile Software Development with a particular focus on one of its most used technique : '''Scrum Methodology'''.

=Scrum Methodology=
Scrum is an iterative method used to develop software, it can be placed inside the group of methods which are used in '''ASD'''. This word is taken from rugby and represents that phase of the match where an ordered formation of players, with arms interlocked and heads down, push forward against a similar group to gain possession of the ball<ref name='Cohen'></ref>. This method provides that "work is divided into small chunks to manage complexity and to get early feedback from customers and end users" (''S. Augustine, 2005'')<ref>S. Augustine,2005,Prentice Hall PTR,Managing Agile Projects</ref>; software development is carried out by small working team that allow rapid adjustment during the process and a quick delivery of the final product.

==Agile Software Development==
At the end of the 20th century there were some practitioners who believed that traditional [[Wikipedia:Iterative model |Iterative model]] was not so responsive to market changes. They defined Agile a process which was able to accept change rather than stress predictability.They also believed that to well face customers’ needs development software methods have to respond to change as quickly as it arose rather than prevent changes.<ref name='Cohen'>D.Cohen,M.Lindval,P. Costa,Fraunhofer Center Maryland, Agile Software Development</ref>

It was in these circumstances that practitioners as Mary Poppendieck and Bob Charet started to take inspiration from Lean manufacturing principles and apply them to software development.
These are the main points ,according to Poppendieck, which make Lean Production so successful and that can be applied to software development:

*elimination of waste that does not add value to the customer such as diagram and models that do not add value to the final deliverable;
*minimize inventory such as requirements and design documents;
*maximize flow by using iterative development to reduce development time;
*pull from demand;
*empower workers that means “tell developer what needs to be done not how to do it";
*meet customer requirements – work closely with the customer, allowing them to change their minds
*do it right the first time – test early and refactor when necessary;
*abolish local optimization – flexibly manage scope;
*partner with suppliers – avoid adversarial relationships, work towards developing the best software;
*create a culture of continuous improvement – allow the process to improve, learn from mistakes and successes.<ref name='Cohen'></ref><ref>M. Poppendieck, T. Poppendieck, 2003, Addison Wesley, Lean Software Development: An Agile Toolkit[[http://www.poppendieck.com/]]</ref>

===Manifesto for the Agile Software development===
A few years before Poppoendieck’s publication, on February 2001,a group of seventeen software developers published in a work called “Manifesto for the Agile Software Development”<ref name='Manifesto'>K. Beck et al., 2001, Manifesto for Agile Software Development[http://www.agilemanifesto.org/]</ref> the main principles of Agile Software development.

From reading these few words it is possible to identify what are the main innovations that ASD introduced in Software development:
[[File:Agilemanifesto.jpg|400px|thumb|right|Manifesto for the Agile Software development<ref name='Manifesto'></ref>]]

*'''“Individuals and interactions”''': with these words founders want to remark the power of human being creativity and also the ability of each man to collaborate with his other similar. The stiffness of Waterfall model is instead represented by “processes and tools” where people was used to follow only what the plan required.
*'''“Working software“''': here there is a clear reference to the new way of developing software where at every iteration a working program is realised. This is different from the previous model in which a working program couldn’t be seen until the end of the project. This feature is put over the “comprehensive documentation” which characterizes especially Waterfall model.
*'''“Customer collaboration”''': it means that there must be a straight relationship between customer and developer in order to define time by time the projects requirements and evaluate every realise.
*'''“Responding to change over following a plan”''': this sentence encloses the essence of Agile software Development that is to cope with turbulent markets by being flexible and by responding quickly to change. This concept was remarked by the founders in one of the twelve principles which follow the manifesto which says “Welcome changing requirements, even late in development […]”.<ref name='Manifesto'></ref>

=Application=
[[File:Scrum_Framework.png|350px|thumb|right|Scrum Framework]]
There are two concepts that are at the basement of Scrum methodology: '''iterative development''' and '''team working'''. Developing in iterations allow Scrum team to adapt quickly to changing requirements, while working in close location and focusing on communication allow team to make decisions and act on them immediately rather than wait on correspondence.<ref name='Cohen'></ref>

Basically Scrum consists in a sequence of fixed-length iterations called '''Sprint''' that are the fundamental units in which the whole project is divided. As the picture shows Scrum framework is really simple: it starts from a vision like all projects. This idea is converted into a plan during the preliminary meetings where customers and developers identifies the main software requirements and defines the Product Backlog. This represents the entire amount of work that has to be done in order to develop the software. In the next step Product Backlog is divided into several Sprint Backlogs that define which tasks have to be done during the following Sprint. During these iterations the product experiences an incremental development at the end of which it is potentially shippable.

Every Sprint is managed by one or more '''cross-functional and self-organizing teams''' each composed by seven people. There are also other two actors whose task is to be supportive of the software development. One is the '''Product Owner''' who mainly handles customers contacts, and the other is the '''Scrum Master''' whose main task is to ensure that development team can work without obstacles.

Each sprint usually lasts from 2 to 4 weeks, in this period there are at least one meeting between the Product Owner and Development Team in order to define the main objectives; then there are also short daily meetings held every morning to enhance communication, inform customers, developers, and managers on the status of the project, identify any problems encountered, and keep the entire team focused on a common goal.<ref name='Cohen'></ref>

==Main Actors in Scrum==
===Product Owner===
Product owner is the link between customers and development team, he ensures that deliverables are in line with customers’ expectation and that stakeholders’ interests are fulfilled. He has also the task to fill out customer-centric items (typically '''user stories'''), ranks and prioritizes them before adds them to the '''Product Backlog'''.

Usually development teams have only one Product owner, but differently from the Scrum master, he only takes care of the business side and does not interfere with the scrum team about the technological issues. At the beginning of each Sprint the Product Owner holds a Sprint Planning Meeting to state on which Product Backlog Items Scrum team will go to work during the next Sprint. In this phase he defines what are the most important items for that business, in according to the customer’s needs.

===Development Team===
Development team task is to deliver Product Backlog Items (PBIs) at the end of every Sprint in according with customers’ requirements.
Usually each team is composed by '''cross-functional members''' that allow an all-round software development; the main figures that there must be are a mix of software engineers, architects, programmers, analysts, QA experts, testers, and UI designers.

The size of the team is an important point, the group members' number influences capacity of people to communicate and work together: it is recommended that a scrum team is composed not more than nine people, usually seven.

Another peculiarity of Scrum team is its Self-organization which facilitates members’ creativity and increases team cohesiveness. For this reason it is recommended to not change the members of a team after they have worked together, especially if they had success in their project. After working together team members gain a mutual understanding that increases their capacity of team working, this synergy cannot be acquired if team are continuously changed.

A further point that characterized the good outcomes of a scrum team is location: people are most successful when located in the same room, particularly for the first few Sprints, this facilitates communication and information sharing.

====Team self-organization====
Team self-organization is a crucial point in the scrum methodology. This new concept is well explained in the sentence “it is told developer what needs to be done not how to do it”<ref name='Cohen'></ref>. It means that they can autonomously choose the way to reach commitments.
Furthermore, as it is explained previously, during Sprint execution team members develop an intrinsic interest in shared goals, in this way self-organizing teams can radically outperform larger than traditionally managed teams. It has to be specified that an optimal self-organization takes time: it may be possible that for the first few sprints developers perform worse than when they work in the traditional way.

Some requirements are necessary to gain a good team self-organization:
*members are committed to clear, short-term goals;
*members can gauge the group’s progress;
*members can observe each other’s contribution;
*members feel safe to give each other unvarnished feedback.<ref name='James'>M. James,2010,Scrum Reference Card, Michael James,[[http://scrumreferencecard.com/]]</ref>

Conversely there are some conditions that can hamper self-organization:
*geographical distribution: it is better if the whole team work in a room;
*boss/work dynamics: each member has to consider the others as peer to facilitate a fair communication between them;
*part-time team members;
*interruptions unrelated to Sprint goals.

===Scrum Master===
The scrum master worries that Scrum team can work without obstacles but he has no management authority over them. Essentially he has the aim to:
*create an environment to promote team self-organization;
*support team in the achievement of expected goals;
*ensure that events (e.g. daily Scrum meeting) take place in the right way;
*keep '''Scrum artefacts''' visible ('''Product Backlog''', '''Sprint Backlog''', '''Sprint burndown chart''' …).

==Sprint==
As it is already explained before Sprint (or iteration) is the fundamental unit in which the whole project is divided. It is characterized by a fixed length of 2 weeks or 30 days and by a goal to achieve. At the beginning of each sprint Scrum team , Product Owner , Scrum Master and sometimes also stakeholders hold a meeting, called Sprint Planning meeting. During this encounter it is defined the Sprint Backlog which states what are the goals and requirements of the next Sprint. After this, further meetings inside development team will be held in order to define in more detail how achieving the common goals stated in the previous meetings.

==Scrum Meetings==
[[File:Scrum_meetings.png|350px|thumb|right|Scrum Meetings<ref name='James'></ref>]]
Meetings are the fundamental tool used during the whole Scrum process. Usually they are facilitated by the Scrum master who however has no decision-making authority over them. There are different typologies of meetings according to the different phase of the process in which we are.
===Sprint Planning Meeting===
At the beginning of each Sprint, the Product Owner and team hold a Sprint Planning Meeting to define on which '''Product Backlog Items (PBIs)''' they will go to work during the next Sprint. During this meeting "The Product Owner is responsible for declaring which items are the most important to the business" instead "the team is responsible for selecting the amount of work they feel they can implement" (''M. James, 2010'')<ref name='James'></ref>.In this phase in perfect Lean perspective Scrum team “pulls” work from the Product Backlog to the Sprint Backlog. At the end of the meeting the selected items are broken into a provisional list of Sprint task. The maximum time that can be used to do Planning meeting, known as '''timebox''', is of eight hours.

===Daily Scrum and Sprint Execution===
During the sprint every day members of the Scrum team hold a fifteen minutes meeting where they take stock of the situation. Usually they speak about what they did the previous day, which impediments they faced and what they are going to do in the current day. To make these meetings shorter it is better that people are standing.
During sprint execution it is common to find out additional tasks necessary to achieve sprint goal; to keep the control over processes during sprint development it could be useful to maintain a current '''Sprint Task List''', a '''Sprint Burndown Chart''', and an '''Impediments List''': these are some artefacts that allow developer to understand where the project is located.

===Sprint Review Meeting===
At the end of every Sprint it is held a Review meeting where the scrum team has to explain to the Product Owner what they did during the previous sprint. Usually this meeting consists in a live demonstration of the working product increment after which Product Owner states which Items can be considered as done.
Items which are declared not done have to return to the Product Backlog to be ranked and reprioritized by the Product Owner with the help of the Scrum master. Last step of this meeting is to convert stakeholders’ feedback to a new Product Log, this task is consigned to both Product Owner and Scrum Master.
The Sprint Review Meeting is the appropriate meeting for external stakeholders (even end users) to attend.

===Sprint Retrospective Meeting===
During this meeting every member of the scrum team inspects his behaviour to identify some impediments that he faced during the Sprint. There are mainly three kind of impediments in which developers can be involved:
*people who conduct performance evaluation are an obstacles to transparency of the team;
*human tendency of someone in the team to jump to conclusions and propose actions too quickly;
*geographical distribution of the team can be an impediments, team work better if they are delimited in a small place like a room.<ref name='James'></ref>

After identifying all these impediments Scrum master has the task to eliminate them.

===Backlog Refinement Meeting ===
Especially at the beginning of the project "most of the Product Backlog Items (PBIs) need refinement because they are too large and poorly understood" (''M. James, 2010'')<ref name='James'></ref>. In the Backlog Refinement Meeting, the gives an estimation of the remaining work that is required to complete the Items in the Product Backlog and provides other technical informations in order to help the Product Owner to prioritize them.

==Artefacts==
[[File:Product_Backlog_2.png|350px|thumb|right|Product Backlog and Sprint Backlog<ref name='James'></ref>]]
===Product Backlog===

It is defined before the project beginning and then upgraded during the Backlog Refinement meeting ; it is made up by the whole group of items which have to be completed during the project in order to realize the final product. Every item is ranked and constantly reprioritized by the Product Owner. It is important that Product Backlog is visible to the stakeholders.

===Product Backlog Item (PBI)===
An item specifies what has to be done but not how do it. Usually they are written in a User story to be understood also by stakeholders. Every items has a work load of 2-3 days and requires 2-3 people. It represents the basic unit of the Product backlog.
[[File:Sprint_Backlog.png|200px|thumb|right|Sprint Backlog<ref name='James'></ref>]]
===Sprint backlog===

It is defined at the beginning of each sprint during the Sprint Planning meeting where the committed items and the main task that have to be done during the sprint are identified. It has to be visible to the Scrum team and also upgraded during the sprint execution with the additional tasks necessary to achieve the final goal.

===Sprint task===
Every item is divided into several tasks, each of them requires one day or less of work. A sprint task specifies how to achieve what is required by PBI. If the task takes more than one day of work, remaining effort is re-estimated daily, typically in hours.

===Sprint Burndown Chart===
[[File:Sprint_burndown_chart.png|300px|thumb|right|Sprint Burndown Chart<ref name='James'></ref>]]
This tool is used to facilitate self-organization of the team. It indicates the total remaining team task hours within one Sprint. Usually chart shows a decreasing line but if there are some re-estimation it may be possible that line increase for then going down. As picture shows it has a time line in the x axis and the remaining hours of work within one Sprint in the y axis. The advantage of this tool is to show at a first sight at which point of the project you are and the work that is left to complete the Sprint. It is important that this tool is used only as help to Scrum team; in some situations it could become a constraint for developers, in this case Scrum Master has to remove this chart from the room.

=Limitations=
Scrum method was often used in the object-oriented software development. Actually this technique are applied not only on software but also on other products from different sectors like wheelchairs, semiconductors and mortgages.
Scrum has to be used in those projects where people cannot rely on the plan-driven approaches like Waterfall, because of unknown requirements and technology.
[[File:Graph.png|300px|thumb|right|Predictability of a Project<ref name='James'></ref>]]
Conversely if the projects is placed under precise and stable conditions it is better to use one of the traditional model which allow to have a fixed planning over the whole project. In this case Scrum method would involve in a waste of resources and money because he is working on a field that is not its responsibility.

Michael James in his “Scrum Reference card” explains with a simple graphics in which conditions Scrum should be used and which ones are not. James defines the predictability of the projects on the base of two features: knowledge of the requirements and knowledge of the level of technology required. A project which provides known requirements and a known level of technology should be carried out with a plan-driven model. It these conditions are not met it is better to use an empirical approach like Scrum.<ref name='James'></ref>

=References=
<references/>

Scrum Methodology in Agile Software Development

2015-09-28T21:56:46Z

S150821:

Today market is affected by uncertainly and sudden changes, in these conditions most of the models used in the 20th century to develop software are not still appropriate.[[Wikipedia:Waterfall model | Waterfall model]] , probably the most famous between them, is characterized by a stiff structure which can’t cope with the turbulent needs of the actual market.
In recent years many innovations are been enhanced in software engineering with a particular focus on the flexibility of these methods in order to cope with the customers' and markets' needs; surely [[Wikipedia: Agile Software Development |Agile Software Development (ASD)]] is between them.

ASD embraces the principles of [[Wikipedia:Lean Production|Lean Production]] by applying them in software development to avoid waste and increase responsiveness to change. It represents the solution to the unpredictability of the market where the capacity "to welcome change even late in development" (''K. Beck et all, 2001'')<ref name='Manifesto'></ref> is required.
This article deals with Agile Software Development with a particular focus on one of its most used technique : '''Scrum Methodology'''.

=Scrum Methodology=
Scrum is an iterative method used to develop software, it can be placed inside the group of methods which are used in '''ASD'''. This word is taken from rugby and represents that phase of the match where an ordered formation of players, with arms interlocked and heads down, push forward against a similar group to gain possession of the ball<ref name='Cohen'></ref>. This method provides that "work is divided into small chunks to manage complexity and to get early feedback from customers and end users" (''S. Augustine, 2005'')<ref>S. Augustine,2005,Prentice Hall PTR,Managing Agile Projects</ref>; software development is carried out by small working team that allow rapid adjustment during the process and a quick delivery of the final product.

==Agile Software Development==
At the end of the 20th century there were some practitioners who believed that traditional [[Wikipedia:Iterative model |Iterative model]] was not so responsive to market changes. They defined Agile a process which was able to accept change rather than stress predictability.They also believed that to well face customers’ needs development software methods have to respond to change as quickly as it arose rather than prevent changes.<ref name='Cohen'>D.Cohen,M.Lindval,P. Costa,Fraunhofer Center Maryland, Agile Software Development</ref>

It was in these circumstances that practitioners as Mary Poppendieck and Bob Charet started to take inspiration from Lean manufacturing principles and apply them to software development.
These are the main points ,according to Poppendieck, which make Lean Production so successful and that can be applied to software development:

*elimination of waste that does not add value to the customer such as diagram and models that do not add value to the final deliverable;
*minimize inventory such as requirements and design documents;
*maximize flow by using iterative development to reduce development time;
*pull from demand;
*empower workers that means “tell developer what needs to be done not how to do it";
*meet customer requirements – work closely with the customer, allowing them to change their minds
*do it right the first time – test early and refactor when necessary;
*abolish local optimization – flexibly manage scope;
*partner with suppliers – avoid adversarial relationships, work towards developing the best software;
*create a culture of continuous improvement – allow the process to improve, learn from mistakes and successes.<ref name='Cohen'></ref><ref>M. Poppendieck, T. Poppendieck, 2003, Addison Wesley, Lean Software Development: An Agile Toolkit[[http://www.poppendieck.com/]]</ref>

===Manifesto for the Agile Software development===
A few years before Poppoendieck’s publication, on February 2001,a group of seventeen software developers published in a work called “Manifesto for the Agile Software Development”<ref name='Manifesto'>K. Beck et al., 2001, Manifesto for Agile Software Development[http://www.agilemanifesto.org/]</ref> the main principles of Agile Software development.

From reading these few words it is possible to identify what are the main innovations that ASD introduced in Software development:
[[File:Agilemanifesto.jpg|400px|thumb|right|Manifesto for the Agile Software development<ref name='Manifesto'></ref>]]

*'''“Individuals and interactions”''': with these words founders want to remark the power of human being creativity and also the ability of each man to collaborate with his other similars. The stiffness of Waterfall model is instead represented by “processes and tools” where people was used to follow only what the plan required.
*'''“Working software“''': here there is a clear reference to the new way of developing software where at every iteration a working program is realised. This is different from the previous model in which a working program couldn’t be seen until the end of the project. This feature is put over the “comprehensive documentation” which characterizes especially Waterfall model.
*'''“Customer collaboration”''': it means that there must be a straight relationship between customer and developer in order to define time by time the projects requirements and evaluate every realise.
*'''“Responding to change over following a plan”''' : this sentence encloses the essence of Agile software Development that is to cope with turbulent markets by being flexible and by responding quickly to change. This concept was remarked by the founders in one of the twelve principles which follow the manifesto which says “Welcome changing requirements, even late in development […]”.<ref name='Manifesto'></ref>

=Application=
[[File:Scrum_Framework.png|350px|thumb|right|Scrum Framework]]
There are two concepts that are at the basement of Scrum methodology: '''iterative development''' and '''team working'''. Developing in iterations allow Scrum team to adapt quickly to changing requirements, while working in close location and focusing on communication allow team to make decisions and act on them immediately rather than wait on correspondence.<ref name='Cohen'></ref>

Basically Scrum consists in a sequence of fixed-length iterations called '''Sprint''' that are the fundamental units in which the whole project is divided. As the picture shows Scrum framework is really simple: it starts from a vision like all projects. This idea is converted into a plan during the preliminary meetings where customers and developers identifies the main software requirements and defines the Product Backlog. This represents the entire amount of work that has to be done in order to develop the software. In the next step Product Backlog is divided into several Sprint Backlogs that define which tasks have to be done during the following Sprint. During these iterations the product experiences an incremental development at the end of which it is potentially shippable.

Every Sprint is managed by one or more '''cross-functional and self-organizing teams''' each composed by seven people. There are also other two actors whose task is to be supportive of the software development. One is the '''Product Owner''' who mainly handles customers contacts, and the other is the '''Scrum Master''' whose main task is to ensure that development team can work without obstacles.

Each sprint usually lasts from 2 to 4 weeks, in this period there are at least one meeting between the Product Owner and Development Team in order to define the main objectives; then there are also short daily meetings held every morning to enhance communication, inform customers, developers, and managers on the status of the project, identify any problems encountered, and keep the entire team focused on a common goal.<ref name='Cohen'></ref>

==Main Actors in Scrum==
===Product Owner===
Product owner is the link between customers and development team, he ensures that deliverables are in line with customers’ expectation and that stakeholders’ interests are fulfilled. He has also the task to fill out customer-centric items (typically '''user stories'''), ranks and prioritizes them before adds them to the '''Product Backlog'''.

Usually development teams have only one Product owner, but differently from the Scrum master, he only takes care of the business side and does not interfere with the scrum team about the technological issues. At the beginning of each Sprint the Product Owner holds a Sprint Planning Meeting to state on which Product Backlog Items Scrum team will go to work during the next Sprint. In this phase he defines what are the most important items for that business, in according to the customer’s needs.

===Development Team===
Development team task is to deliver Product Backlog Items (PBIs) at the end of every Sprint in according with customers’ requirements.
Usually each team is composed by '''cross-functional members''' that allow an all-round software development; the main figures that there must be are a mix of software engineers, architects, programmers, analysts, QA experts, testers, and UI designers.

The size of the team is an important point, the group members' number influences capacity of people to communicate and work together: it is recommended that a scrum team is composed not more than nine people, usually seven.

Another peculiarity of Scrum team is its Self-organization which facilitates members’ creativity and increases team cohesiveness. For this reason it is recommended to not change the members of a team after they have worked together, especially if they had success in their project. After working together team members gain a mutual understanding that increases their capacity of team working, this synergy cannot be acquired if team are continuously changed.

A further point that characterized the good outcomes of a scrum team is location: people are most successful when located in the same room, particularly for the first few Sprints, this facilitates communication and information sharing.

====Team self-organization====
Team self-organization is a crucial point in the scrum methodology. This new concept is well explained in the sentence “it is told developer what needs to be done not how to do it”<ref name='Cohen'></ref>. It means that they can autonomously choose the way to reach commitments.
Furthermore, as it is explained previously, during Sprint execution team members develop an intrinsic interest in shared goals, in this way self-organizing teams can radically outperform larger than traditionally managed teams. It has to be specified that an optimal self-organization takes time: it may be possible that for the first few sprints developers perform worse than when they work in the traditional way.

Some requirements are necessary to gain a good team self-organization:
*members are committed to clear, short-term goals;
*members can gauge the group’s progress;
*members can observe each other’s contribution;
*members feel safe to give each other unvarnished feedback.<ref name='James'>M. James,2010,Scrum Reference Card, Michael James,[[http://scrumreferencecard.com/]]</ref>

Conversely there are some conditions that can hamper self-organization:
*geographical distribution: it is better if the whole team work in a room;
*boss/work dynamics: each member has to consider the others as peer to facilitate a fair communication between them;
*part-time team members;
*interruptions unrelated to Sprint goals.

===Scrum Master===
The scrum master worries that Scrum team can work without obstacles but he has no management authority over them. Essentially he has the aim to:
*create an environment to promote team self-organization;
*support team in the achievement of expected goals;
*ensure that events (e.g. daily Scrum meeting) take place in the right way;
*keep '''Scrum artefacts''' visible ('''Product Backlog''', '''Sprint Backlog''', '''Sprint burndown chart''' …).

==Sprint==
As it is already explained before Sprint (or iteration) is the fundamental unit in which the whole project is divided. It is characterized by a fixed length of 2 weeks or 30 days and by a goal to achieve. At the beginning of each sprint Scrum team , Product Owner , Scrum Master and sometimes also stakeholders hold a meeting, called Sprint Planning meeting. During this encounter it is defined the Sprint Backlog which states what are the goals and requirements of the next Sprint. After this, further meetings inside development team will be held in order to define in more detail how achieving the common goals stated in the previous meetings.

==Scrum Meetings==
[[File:Scrum_meetings.png|350px|thumb|right|Scrum Meetings<ref name='James'></ref>]]
Meetings are the fundamental tool used during the whole Scrum process. Usually they are facilitated by the Scrum master who however has no decision-making authority over them. There are different typologies of meetings according to the different phase of the process in which we are.
===Sprint Planning Meeting===
At the beginning of each Sprint, the Product Owner and team hold a Sprint Planning Meeting to define on which '''Product Backlog Items (PBIs)''' they will go to work during the next Sprint. During this meeting "The Product Owner is responsible for declaring which items are the most important to the business" instead "the team is responsible for selecting the amount of work they feel they can implement" (''M. James, 2010'')<ref name='James'></ref>.In this phase in perfect Lean perspective Scrum team “pulls” work from the Product Backlog to the Sprint Backlog. At the end of the meeting the selected items are broken into a provisional list of Sprint task. The maximum time that can be used to do Planning meeting, known as '''timebox''', is of eight hours.

===Daily Scrum and Sprint Execution===
During the sprint every day members of the Scrum team hold a fifteen minutes meeting where they take stock of the situation. Usually they speak about what they did the previous day, which impediments they faced and what they are going to do in the current day. To make these meetings shorter it is better that people are standing.
During sprint execution it is common to find out additional tasks necessary to achieve sprint goal; to keep the control over processes during sprint development it could be useful to maintain a current '''Sprint Task List''', a '''Sprint Burndown Chart''', and an '''Impediments List''': these are some artefacts that allow developer to understand where the project is located.

===Sprint Review Meeting===
At the end of every Sprint it is held a Review meeting where the scrum team has to explain to the Product Owner what they did during the previous sprint. Usually this meeting consists in a live demonstration of the working product increment after which Product Owner states which Items can be considered as done.
Items which are declared not done have to return to the Product Backlog to be ranked and reprioritized by the Product Owner with the help of the Scrum master. Last step of this meeting is to convert stakeholders’ feedback to a new Product Log, this task is consigned to both Product Owner and Scrum Master.
The Sprint Review Meeting is the appropriate meeting for external stakeholders (even end users) to attend.

===Sprint Retrospective Meeting===
During this meeting every member of the scrum team inspects his behaviour to identify some impediments that he faced during the Sprint. There are mainly three kind of impediments in which developers can be involved:
*people who conduct performance evaluation are an obstacles to transparency of the team;
*human tendency of someone in the team to jump to conclusions and propose actions too quickly;
*geographical distribution of the team can be an impediments, team work better if they are delimited in a small place like a room.<ref name='James'></ref>

After identifying all these impediments Scrum master has the task to eliminate them.

===Backlog Refinement Meeting ===
Especially at the beginning of the project "most of the Product Backlog Items (PBIs) need refinement because they are too large and poorly understood" (''M. James, 2010'')<ref name='James'></ref>. In the Backlog Refinement Meeting, the gives an estimation of the remaining work that is required to complete the Items in the Product Backlog and provides other technical informations in order to help the Product Owner to prioritize them.

==Artefacts==
[[File:Product_Backlog_2.png|350px|thumb|right|Product Backlog and Sprint Backlog<ref name='James'></ref>]]
===Product Backlog===

It is defined before the project beginning and then upgraded during the Backlog Refinement meeting ; it is made up by the whole group of items which have to be completed during the project in order to realize the final product. Every item is ranked and constantly reprioritized by the Product Owner. It is important that Product Backlog is visible to the stakeholders.

===Product Backlog Item (PBI)===
An item specifies what has to be done but not how do it. Usually they are written in a User story to be understood also by stakeholders. Every items has a work load of 2-3 days and requires 2-3 people. It represents the basic unit of the Product backlog.
[[File:Sprint_Backlog.png|200px|thumb|right|Sprint Backlog<ref name='James'></ref>]]
===Sprint backlog===

It is defined at the beginning of each sprint during the Sprint Planning meeting where the committed items and the main task that have to be done during the sprint are identified. It has to be visible to the Scrum team and also upgraded during the sprint execution with the additional tasks necessary to achieve the final goal.

===Sprint task===
Every item is divided into several tasks, each of them requires one day or less of work. A sprint task specifies how to achieve what is required by PBI. If the task takes more than one day of work, remaining effort is re-estimated daily, typically in hours.

===Sprint Burndown Chart===
[[File:Sprint_burndown_chart.png|300px|thumb|right|Sprint Burndown Chart<ref name='James'></ref>]]
This tool is used to facilitate self-organization of the team. It indicates the total remaining team task hours within one Sprint. Usually chart shows a decreasing line but if there are some re-estimation it may be possible that line increase for then going down. As picture shows it has a time line in the x axis and the remaining hours of work within one Sprint in the y axis. The advantage of this tool is to show at a first sight at which point of the project you are and the work that is left to complete the Sprint. It is important that this tool is used only as help to Scrum team; in some situations it could become a constraint for developers, in this case Scrum Master has to remove this chart from the room.

=Limitations=
Scrum method was often used in the object-oriented software development. Actually this technique are applied not only on software but also on other products from different sectors like wheelchairs, semiconductors and mortgages.
Scrum has to be used in those projects where people cannot rely on the plan-driven approaches like Waterfall, because of unknown requirements and technology.
[[File:Graph.png|300px|thumb|right|Predictability of a Project<ref name='James'></ref>]]
Conversely if the projects is placed under precise and stable conditions it is better to use one of the traditional model which allow to have a fixed planning over the whole project. In this case Scrum method would involve in a waste of resources and money because he is working on a field that is not its responsibility.

Michael James in his “Scrum Reference card” explains with a simple graphics in which conditions Scrum should be used and which ones are not. James defines the predictability of the projects on the base of two features: knowledge of the requirements and knowledge of the level of technology required. A project which provides known requirements and a known level of technology should be carried out with a plan-driven model. It these conditions are not met it is better to use an empirical approach like Scrum.<ref name='James'></ref>

=References=
<references/>

Scrum Methodology in Agile Software Development

2015-09-28T21:51:00Z

S150821: /* Sprint Planning Meeting */

Today market is affected by uncertainly and sudden changes, in these conditions most of the models used in the 20th century to develop software are not still appropriate.[[Wikipedia:Waterfall model | Waterfall model]] , probably the most famous between them, is characterized by a stiff structure which can’t cope with the turbulent needs of the actual market.
In recent years many innovations are been enhanced in software engineering with a particular focus on the flexibility of these methods in order to cope with the customers' and markets' needs; surely [[Wikipedia: Agile Software Development |Agile Software Development (ASD)]] is between them.

ASD embraces the principles of [[Wikipedia:Lean Production|Lean Production]] by applying them in software development to avoid waste and increase responsiveness to change. It represents the solution to the unpredictability of the market where the capacity "to welcome change even late in development" (''K. Beck et all, 2001'')<ref name='Manifesto'></ref> is required.
This article deals with Agile Software Development with a particular focus on one of its most used technique : '''Scrum Methodology'''.

=Scrum Methodology=
Scrum is an iterative method used to develop software, it can be placed inside the group of methods which are used in '''ASD'''. This word is taken from rugby and represents that phase of the match where an ordered formation of players, with arms interlocked and heads down, push forward against a similar group to gain possession of the ball<ref name='Cohen'></ref>. This method provides that "work is divided into small chunks to manage complexity and to get early feedback from customers and end users" (''S. Augustine, 2005'')<ref>S. Augustine,2005,Prentice Hall PTR,Managing Agile Projects</ref>; software development is carried out by small working team that allow rapid adjustment during the process and a quick delivery of the final product.

==Agile Software Development==
At the end of the 20th century there were some practitioners who believed that traditional [[Wikipedia:Iterative model |Iterative model]] was not so responsive to market changes. They defined Agile a process which was able to accept change rather than stress predictability.They also believed that to well face customers’ needs development software methods have to respond to change as quickly as it arose rather than prevent changes.<ref name='Cohen'>D.Cohen,M.Lindval,P. Costa,Fraunhofer Center Maryland, Agile Software Development</ref>

It was in these circumstances that practitioners as Mary Poppendieck and Bob Charet started to take inspiration from Lean manufacturing principles and apply them to software development.
These are the main points ,according to Poppendieck, which make Lean Production so successful and that can be applied to software development:

*elimination of waste that does not add value to the customer such as diagram and models that do not add value to the final deliverable;
*minimize inventory such as requirements and design documents;
*maximize flow by using iterative development to reduce development time;
*pull from demand;
*empower workers that means “tell developer what needs to be done not how to do it";
*meet customer requirements – work closely with the customer, allowing them to change their minds
*do it right the first time – test early and refactor when necessary;
*abolish local optimization – flexibly manage scope;
*partner with suppliers – avoid adversarial relationships, work towards developing the best software;
*create a culture of continuous improvement – allow the process to improve, learn from mistakes and successes.<ref name='Cohen'></ref><ref>M. Poppendieck, T. Poppendieck, 2003, Addison Wesley, Lean Software Development: An Agile Toolkit[[http://www.poppendieck.com/]]</ref>

===Manifesto for the Agile Software development===
A few years before Poppoendieck’s publication, on February 2001,a group of seventeen software developers published in a work called “Manifesto for the Agile Software Development”<ref name='Manifesto'>K. Beck et all., 2001, Manifesto for Agile Software Development[http://www.agilemanifesto.org/]</ref> the main principles of Agile Software development.

From reading these few words it is possible to identify what are the main innovations that ASD introduced in Software development:
[[File:Agilemanifesto.jpg|400px|thumb|right|Manifesto for the Agile Software development<ref name='Manifesto'></ref>]]

*'''“Individuals and interactions”''': with these words founders want to remark the power of human being creativity and also the ability of each man to collaborate with his other similars. The stiffness of Waterfall model is instead represented by “processes and tools” where people was used to follow only what the plan required.
*'''“Working software“''': here there is a clear reference to the new way of developing software where at every iteration a working program is realised. This is different from the previous model in which a working program couldn’t be seen until the end of the project. This feature is put over the “comprehensive documentation” which characterizes especially Waterfall model.
*'''“Customer collaboration”''': it means that there must be a straight relationship between customer and developer in order to define time by time the projects requirements and evaluate every realise.
*'''“Responding to change over following a plan”''' : this sentence encloses the essence of Agile software Development that is to cope with turbulent markets by being flexible and by responding quickly to change. This concept was remarked by the founders in one of the twelve principles which follow the manifesto which says “Welcome changing requirements, even late in development […]”.<ref name='Manifesto'></ref>

=Application=
[[File:Scrum_Framework.png|350px|thumb|right|Scrum Framework]]
There are two concepts that are at the basement of Scrum methodology: '''iterative development''' and '''team working'''. Developing in iterations allow Scrum team to adapt quickly to changing requirements, while working in close location and focusing on communication allow team to make decisions and act on them immediately rather than wait on correspondence.<ref name='Cohen'></ref>

Basically Scrum consists in a sequence of fixed-length iterations called '''Sprint''' that are the fundamental units in which the whole project is divided. As the picture shows Scrum framework is really simple: it starts from a vision like all projects. This idea is converted into a plan during the preliminary meetings where customers and developers identifies the main software requirements and defines the Product Backlog. This represents the entire amount of work that has to be done in order to develop the software. In the next step Product Backlog is divided into several Sprint Backlogs that define which tasks have to be done during the following Sprint. During these iterations the product experiences an incremental development at the end of which it is potentially shippable.

Every Sprint is managed by one or more '''cross-functional and self-organizing teams''' each composed by seven people. There are also other two actors whose task is to be supportive of the software development. One is the '''Product Owner''' who mainly handles customers contacts, and the other is the '''Scrum Master''' whose main task is to ensure that development team can work without obstacles.

Each sprint usually lasts from 2 to 4 weeks, in this period there are at least one meeting between the Product Owner and Development Team in order to define the main objectives; then there are also short daily meetings held every morning to enhance communication, inform customers, developers, and managers on the status of the project, identify any problems encountered, and keep the entire team focused on a common goal.<ref name='Cohen'></ref>

==Main Actors in Scrum==
===Product Owner===
Product owner is the link between customers and development team, he ensures that deliverables are in line with customers’ expectation and that stakeholders’ interests are fulfilled. He has also the task to fill out customer-centric items (typically '''user stories'''), ranks and prioritizes them before adds them to the '''Product Backlog'''.

Usually development teams have only one Product owner, but differently from the Scrum master, he only takes care of the business side and does not interfere with the scrum team about the technological issues. At the beginning of each Sprint the Product Owner holds a Sprint Planning Meeting to state on which Product Backlog Items Scrum team will go to work during the next Sprint. In this phase he defines what are the most important items for that business, in according to the customer’s needs.

===Development Team===
Development team task is to deliver Product Backlog Items (PBIs) at the end of every Sprint in according with customers’ requirements.
Usually each team is composed by '''cross-functional members''' that allow an all-round software development; the main figures that there must be are a mix of software engineers, architects, programmers, analysts, QA experts, testers, and UI designers.

The size of the team is an important point, the group members' number influences capacity of people to communicate and work together: it is recommended that a scrum team is composed not more than nine people, usually seven.

Another peculiarity of Scrum team is its Self-organization which facilitates members’ creativity and increases team cohesiveness. For this reason it is recommended to not change the members of a team after they have worked together, especially if they had success in their project. After working together team members gain a mutual understanding that increases their capacity of team working, this synergy cannot be acquired if team are continuously changed.

A further point that characterized the good outcomes of a scrum team is location: people are most successful when located in the same room, particularly for the first few Sprints, this facilitates communication and information sharing.

====Team self-organization====
Team self-organization is a crucial point in the scrum methodology. This new concept is well explained in the sentence “it is told developer what needs to be done not how to do it”<ref name='Cohen'></ref>. It means that they can autonomously choose the way to reach commitments.
Furthermore, as it is explained previously, during Sprint execution team members develop an intrinsic interest in shared goals, in this way self-organizing teams can radically outperform larger than traditionally managed teams. It has to be specified that an optimal self-organization takes time: it may be possible that for the first few sprints developers perform worse than when they work in the traditional way.

Some requirements are necessary to gain a good team self-organization:
*members are committed to clear, short-term goals;
*members can gauge the group’s progress;
*members can observe each other’s contribution;
*members feel safe to give each other unvarnished feedback.<ref name='James'>M. James,2010,Scrum Reference Card, Michael James,[[http://scrumreferencecard.com/]]</ref>

Conversely there are some conditions that can hamper self-organization:
*geographical distribution: it is better if the whole team work in a room;
*boss/work dynamics: each member has to consider the others as peer to facilitate a fair communication between them;
*part-time team members;
*interruptions unrelated to Sprint goals.

===Scrum Master===
The scrum master worries that Scrum team can work without obstacles but he has no management authority over them. Essentially he has the aim to:
*create an environment to promote team self-organization;
*support team in the achievement of expected goals;
*ensure that events (e.g. daily Scrum meeting) take place in the right way;
*keep '''Scrum artefacts''' visible ('''Product Backlog''', '''Sprint Backlog''', '''Sprint burndown chart''' …).

==Sprint==
As it is already explained before Sprint (or iteration) is the fundamental unit in which the whole project is divided. It is characterized by a fixed length of 2 weeks or 30 days and by a goal to achieve. At the beginning of each sprint Scrum team , Product Owner , Scrum Master and sometimes also stakeholders hold a meeting, called Sprint Planning meeting. During this encounter it is defined the Sprint Backlog which states what are the goals and requirements of the next Sprint. After this, further meetings inside development team will be held in order to define in more detail how achieving the common goals stated in the previous meetings.

==Scrum Meetings==
[[File:Scrum_meetings.png|350px|thumb|right|Scrum Meetings<ref name='James'></ref>]]
Meetings are the fundamental tool used during the whole Scrum process. Usually they are facilitated by the Scrum master who however has no decision-making authority over them. There are different typologies of meetings according to the different phase of the process in which we are.
===Sprint Planning Meeting===
At the beginning of each Sprint, the Product Owner and team hold a Sprint Planning Meeting to define on which '''Product Backlog Items (PBIs)''' they will go to work during the next Sprint. During this meeting "The Product Owner is responsible for declaring which items are the most important to the business" instead "the team is responsible for selecting the amount of work they feel they can implement" (''M. James, 2010'')<ref name='James'></ref>.In this phase in perfect Lean perspective Scrum team “pulls” work from the Product Backlog to the Sprint Backlog. At the end of the meeting the selected items are broken into a provisional list of Sprint task. The maximum time that can be used to do Planning meeting, known as '''timebox''', is of eight hours.

===Daily Scrum and Sprint Execution===
During the sprint every day members of the Scrum team hold a fifteen minutes meeting where they take stock of the situation. Usually they speak about what they did the previous day, which impediments they faced and what they are going to do in the current day. To make these meetings shorter it is better that people are standing.
During sprint execution it is common to find out additional tasks necessary to achieve sprint goal; to keep the control over processes during sprint development it could be useful to maintain a current '''Sprint Task List''', a '''Sprint Burndown Chart''', and an '''Impediments List''': these are some artefacts that allow developer to understand where the project is located.

===Sprint Review Meeting===
At the end of every Sprint it is held a Review meeting where the scrum team has to explain to the Product Owner what they did during the previous sprint. Usually this meeting consists in a live demonstration of the working product increment after which Product Owner states which Items can be considered as done.
Items which are declared not done have to return to the Product Backlog to be ranked and reprioritized by the Product Owner with the help of the Scrum master. Last step of this meeting is to convert stakeholders’ feedback to a new Product Log, this task is consigned to both Product Owner and Scrum Master.
The Sprint Review Meeting is the appropriate meeting for external stakeholders (even end users) to attend.

===Sprint Retrospective Meeting===
During this meeting every member of the scrum team inspects his behaviour to identify some impediments that he faced during the Sprint. There are mainly three kind of impediments in which developers can be involved:
*people who conduct performance evaluation are an obstacles to transparency of the team;
*human tendency of someone in the team to jump to conclusions and propose actions too quickly;
*geographical distribution of the team can be an impediments, team work better if they are delimited in a small place like a room.<ref name='James'></ref>

After identifying all these impediments Scrum master has the task to eliminate them.

===Backlog Refinement Meeting ===
Especially at the beginning of the project "most of the Product Backlog Items (PBIs) need refinement because they are too large and poorly understood" (''M. James, 2010'')<ref name='James'></ref>. In the Backlog Refinement Meeting, the gives an estimation of the remaining work that is required to complete the Items in the Product Backlog and provides other technical informations in order to help the Product Owner to prioritize them.

==Artefacts==
[[File:Product_Backlog_2.png|350px|thumb|right|Product Backlog and Sprint Backlog<ref name='James'></ref>]]
===Product Backlog===

It is defined before the project beginning and then upgraded during the Backlog Refinement meeting ; it is made up by the whole group of items which have to be completed during the project in order to realize the final product. Every item is ranked and constantly reprioritized by the Product Owner. It is important that Product Backlog is visible to the stakeholders.

===Product Backlog Item (PBI)===
An item specifies what has to be done but not how do it. Usually they are written in a User story to be understood also by stakeholders. Every items has a work load of 2-3 days and requires 2-3 people. It represents the basic unit of the Product backlog.
[[File:Sprint_Backlog.png|200px|thumb|right|Sprint Backlog<ref name='James'></ref>]]
===Sprint backlog===

It is defined at the beginning of each sprint during the Sprint Planning meeting where the committed items and the main task that have to be done during the sprint are identified. It has to be visible to the Scrum team and also upgraded during the sprint execution with the additional tasks necessary to achieve the final goal.

===Sprint task===
Every item is divided into several tasks, each of them requires one day or less of work. A sprint task specifies how to achieve what is required by PBI. If the task takes more than one day of work, remaining effort is re-estimated daily, typically in hours.

===Sprint Burndown Chart===
[[File:Sprint_burndown_chart.png|300px|thumb|right|Sprint Burndown Chart<ref name='James'></ref>]]
This tool is used to facilitate self-organization of the team. It indicates the total remaining team task hours within one Sprint. Usually chart shows a decreasing line but if there are some re-estimation it may be possible that line increase for then going down. As picture shows it has a time line in the x axis and the remaining hours of work within one Sprint in the y axis. The advantage of this tool is to show at a first sight at which point of the project you are and the work that is left to complete the Sprint. It is important that this tool is used only as help to Scrum team; in some situations it could become a constraint for developers, in this case Scrum Master has to remove this chart from the room.

=Limitations=
Scrum method was often used in the object-oriented software development. Actually this technique are applied not only on software but also on other products from different sectors like wheelchairs, semiconductors and mortgages.
Scrum has to be used in those projects where people cannot rely on the plan-driven approaches like Waterfall, because of unknown requirements and technology.
[[File:Graph.png|300px|thumb|right|Predictability of a Project<ref name='James'></ref>]]
Conversely if the projects is placed under precise and stable conditions it is better to use one of the traditional model which allow to have a fixed planning over the whole project. In this case Scrum method would involve in a waste of resources and money because he is working on a field that is not its responsibility.

Michael James in his “Scrum Reference card” explains with a simple graphics in which conditions Scrum should be used and which ones are not. James defines the predictability of the projects on the base of two features: knowledge of the requirements and knowledge of the level of technology required. A project which provides known requirements and a known level of technology should be carried out with a plan-driven model. It these conditions are not met it is better to use an empirical approach like Scrum.<ref name='James'></ref>

=References=
<references/>

Scrum Methodology in Agile Software Development

2015-09-28T21:48:57Z

S150821: /* Sprint */

Today market is affected by uncertainly and sudden changes, in these conditions most of the models used in the 20th century to develop software are not still appropriate.[[Wikipedia:Waterfall model | Waterfall model]] , probably the most famous between them, is characterized by a stiff structure which can’t cope with the turbulent needs of the actual market.
In recent years many innovations are been enhanced in software engineering with a particular focus on the flexibility of these methods in order to cope with the customers' and markets' needs; surely [[Wikipedia: Agile Software Development |Agile Software Development (ASD)]] is between them.

ASD embraces the principles of [[Wikipedia:Lean Production|Lean Production]] by applying them in software development to avoid waste and increase responsiveness to change. It represents the solution to the unpredictability of the market where the capacity "to welcome change even late in development" (''K. Beck et all, 2001'')<ref name='Manifesto'></ref> is required.
This article deals with Agile Software Development with a particular focus on one of its most used technique : '''Scrum Methodology'''.

=Scrum Methodology=
Scrum is an iterative method used to develop software, it can be placed inside the group of methods which are used in '''ASD'''. This word is taken from rugby and represents that phase of the match where an ordered formation of players, with arms interlocked and heads down, push forward against a similar group to gain possession of the ball<ref name='Cohen'></ref>. This method provides that "work is divided into small chunks to manage complexity and to get early feedback from customers and end users" (''S. Augustine, 2005'')<ref>S. Augustine,2005,Prentice Hall PTR,Managing Agile Projects</ref>; software development is carried out by small working team that allow rapid adjustment during the process and a quick delivery of the final product.

==Agile Software Development==
At the end of the 20th century there were some practitioners who believed that traditional [[Wikipedia:Iterative model |Iterative model]] was not so responsive to market changes. They defined Agile a process which was able to accept change rather than stress predictability.They also believed that to well face customers’ needs development software methods have to respond to change as quickly as it arose rather than prevent changes.<ref name='Cohen'>D.Cohen,M.Lindval,P. Costa,Fraunhofer Center Maryland, Agile Software Development</ref>

It was in these circumstances that practitioners as Mary Poppendieck and Bob Charet started to take inspiration from Lean manufacturing principles and apply them to software development.
These are the main points ,according to Poppendieck, which make Lean Production so successful and that can be applied to software development:

*elimination of waste that does not add value to the customer such as diagram and models that do not add value to the final deliverable;
*minimize inventory such as requirements and design documents;
*maximize flow by using iterative development to reduce development time;
*pull from demand;
*empower workers that means “tell developer what needs to be done not how to do it";
*meet customer requirements – work closely with the customer, allowing them to change their minds
*do it right the first time – test early and refactor when necessary;
*abolish local optimization – flexibly manage scope;
*partner with suppliers – avoid adversarial relationships, work towards developing the best software;
*create a culture of continuous improvement – allow the process to improve, learn from mistakes and successes.<ref name='Cohen'></ref><ref>M. Poppendieck, T. Poppendieck, 2003, Addison Wesley, Lean Software Development: An Agile Toolkit[[http://www.poppendieck.com/]]</ref>

===Manifesto for the Agile Software development===
A few years before Poppoendieck’s publication, on February 2001,a group of seventeen software developers published in a work called “Manifesto for the Agile Software Development”<ref name='Manifesto'>K. Beck et all., 2001, Manifesto for Agile Software Development[http://www.agilemanifesto.org/]</ref> the main principles of Agile Software development.

From reading these few words it is possible to identify what are the main innovations that ASD introduced in Software development:
[[File:Agilemanifesto.jpg|400px|thumb|right|Manifesto for the Agile Software development<ref name='Manifesto'></ref>]]

*'''“Individuals and interactions”''': with these words founders want to remark the power of human being creativity and also the ability of each man to collaborate with his other similars. The stiffness of Waterfall model is instead represented by “processes and tools” where people was used to follow only what the plan required.
*'''“Working software“''': here there is a clear reference to the new way of developing software where at every iteration a working program is realised. This is different from the previous model in which a working program couldn’t be seen until the end of the project. This feature is put over the “comprehensive documentation” which characterizes especially Waterfall model.
*'''“Customer collaboration”''': it means that there must be a straight relationship between customer and developer in order to define time by time the projects requirements and evaluate every realise.
*'''“Responding to change over following a plan”''' : this sentence encloses the essence of Agile software Development that is to cope with turbulent markets by being flexible and by responding quickly to change. This concept was remarked by the founders in one of the twelve principles which follow the manifesto which says “Welcome changing requirements, even late in development […]”.<ref name='Manifesto'></ref>

=Application=
[[File:Scrum_Framework.png|350px|thumb|right|Scrum Framework]]
There are two concepts that are at the basement of Scrum methodology: '''iterative development''' and '''team working'''. Developing in iterations allow Scrum team to adapt quickly to changing requirements, while working in close location and focusing on communication allow team to make decisions and act on them immediately rather than wait on correspondence.<ref name='Cohen'></ref>

Basically Scrum consists in a sequence of fixed-length iterations called '''Sprint''' that are the fundamental units in which the whole project is divided. As the picture shows Scrum framework is really simple: it starts from a vision like all projects. This idea is converted into a plan during the preliminary meetings where customers and developers identifies the main software requirements and defines the Product Backlog. This represents the entire amount of work that has to be done in order to develop the software. In the next step Product Backlog is divided into several Sprint Backlogs that define which tasks have to be done during the following Sprint. During these iterations the product experiences an incremental development at the end of which it is potentially shippable.

Every Sprint is managed by one or more '''cross-functional and self-organizing teams''' each composed by seven people. There are also other two actors whose task is to be supportive of the software development. One is the '''Product Owner''' who mainly handles customers contacts, and the other is the '''Scrum Master''' whose main task is to ensure that development team can work without obstacles.

Each sprint usually lasts from 2 to 4 weeks, in this period there are at least one meeting between the Product Owner and Development Team in order to define the main objectives; then there are also short daily meetings held every morning to enhance communication, inform customers, developers, and managers on the status of the project, identify any problems encountered, and keep the entire team focused on a common goal.<ref name='Cohen'></ref>

==Main Actors in Scrum==
===Product Owner===
Product owner is the link between customers and development team, he ensures that deliverables are in line with customers’ expectation and that stakeholders’ interests are fulfilled. He has also the task to fill out customer-centric items (typically '''user stories'''), ranks and prioritizes them before adds them to the '''Product Backlog'''.

Usually development teams have only one Product owner, but differently from the Scrum master, he only takes care of the business side and does not interfere with the scrum team about the technological issues. At the beginning of each Sprint the Product Owner holds a Sprint Planning Meeting to state on which Product Backlog Items Scrum team will go to work during the next Sprint. In this phase he defines what are the most important items for that business, in according to the customer’s needs.

===Development Team===
Development team task is to deliver Product Backlog Items (PBIs) at the end of every Sprint in according with customers’ requirements.
Usually each team is composed by '''cross-functional members''' that allow an all-round software development; the main figures that there must be are a mix of software engineers, architects, programmers, analysts, QA experts, testers, and UI designers.

The size of the team is an important point, the group members' number influences capacity of people to communicate and work together: it is recommended that a scrum team is composed not more than nine people, usually seven.

Another peculiarity of Scrum team is its Self-organization which facilitates members’ creativity and increases team cohesiveness. For this reason it is recommended to not change the members of a team after they have worked together, especially if they had success in their project. After working together team members gain a mutual understanding that increases their capacity of team working, this synergy cannot be acquired if team are continuously changed.

A further point that characterized the good outcomes of a scrum team is location: people are most successful when located in the same room, particularly for the first few Sprints, this facilitates communication and information sharing.

====Team self-organization====
Team self-organization is a crucial point in the scrum methodology. This new concept is well explained in the sentence “it is told developer what needs to be done not how to do it”<ref name='Cohen'></ref>. It means that they can autonomously choose the way to reach commitments.
Furthermore, as it is explained previously, during Sprint execution team members develop an intrinsic interest in shared goals, in this way self-organizing teams can radically outperform larger than traditionally managed teams. It has to be specified that an optimal self-organization takes time: it may be possible that for the first few sprints developers perform worse than when they work in the traditional way.

Some requirements are necessary to gain a good team self-organization:
*members are committed to clear, short-term goals;
*members can gauge the group’s progress;
*members can observe each other’s contribution;
*members feel safe to give each other unvarnished feedback.<ref name='James'>M. James,2010,Scrum Reference Card, Michael James,[[http://scrumreferencecard.com/]]</ref>

Conversely there are some conditions that can hamper self-organization:
*geographical distribution: it is better if the whole team work in a room;
*boss/work dynamics: each member has to consider the others as peer to facilitate a fair communication between them;
*part-time team members;
*interruptions unrelated to Sprint goals.

===Scrum Master===
The scrum master worries that Scrum team can work without obstacles but he has no management authority over them. Essentially he has the aim to:
*create an environment to promote team self-organization;
*support team in the achievement of expected goals;
*ensure that events (e.g. daily Scrum meeting) take place in the right way;
*keep '''Scrum artefacts''' visible ('''Product Backlog''', '''Sprint Backlog''', '''Sprint burndown chart''' …).

==Sprint==
As it is already explained before Sprint (or iteration) is the fundamental unit in which the whole project is divided. It is characterized by a fixed length of 2 weeks or 30 days and by a goal to achieve. At the beginning of each sprint Scrum team , Product Owner , Scrum Master and sometimes also stakeholders hold a meeting, called Sprint Planning meeting. During this encounter it is defined the Sprint Backlog which states what are the goals and requirements of the next Sprint. After this, further meetings inside development team will be held in order to define in more detail how achieving the common goals stated in the previous meetings.

==Scrum Meetings==
[[File:Scrum_meetings.png|350px|thumb|right|Scrum Meetings<ref name='James'></ref>]]
Meetings are the fundamental tool used during the whole Scrum process. Usually they are facilitated by the Scrum master who however has no decision-making authority over them. There are different typologies of meetings according to the different phase of the process in which we are.
===Sprint Planning Meeting===
At the beginning of each Sprint, the Product Owner and team hold a Sprint Planning Meeting to define on which '''Product Backlog Items (PBIs)''' they will go to work during the next Sprint. During this meeting "The Product Owner is responsible for declaring which items are the most important to the business" instead "the team is responsible for selecting the amount of work they feel they can implement" (''M. James, 2010'')<ref name='James'></ref>.In this phase in perfect Lean perspective the team “pulls” work from the Product Backlog to the Sprint Backlog. At the end of the meeting the selected items are broken into a provisional list of Sprint task. The maximum time that can be used to do Planning meeting, known as '''timebox''', is of eight hours.

===Daily Scrum and Sprint Execution===
During the sprint every day members of the Scrum team hold a fifteen minutes meeting where they take stock of the situation. Usually they speak about what they did the previous day, which impediments they faced and what they are going to do in the current day. To make these meetings shorter it is better that people are standing.
During sprint execution it is common to find out additional tasks necessary to achieve sprint goal; to keep the control over processes during sprint development it could be useful to maintain a current '''Sprint Task List''', a '''Sprint Burndown Chart''', and an '''Impediments List''': these are some artefacts that allow developer to understand where the project is located.

===Sprint Review Meeting===
At the end of every Sprint it is held a Review meeting where the scrum team has to explain to the Product Owner what they did during the previous sprint. Usually this meeting consists in a live demonstration of the working product increment after which Product Owner states which Items can be considered as done.
Items which are declared not done have to return to the Product Backlog to be ranked and reprioritized by the Product Owner with the help of the Scrum master. Last step of this meeting is to convert stakeholders’ feedback to a new Product Log, this task is consigned to both Product Owner and Scrum Master.
The Sprint Review Meeting is the appropriate meeting for external stakeholders (even end users) to attend.

===Sprint Retrospective Meeting===
During this meeting every member of the scrum team inspects his behaviour to identify some impediments that he faced during the Sprint. There are mainly three kind of impediments in which developers can be involved:
*people who conduct performance evaluation are an obstacles to transparency of the team;
*human tendency of someone in the team to jump to conclusions and propose actions too quickly;
*geographical distribution of the team can be an impediments, team work better if they are delimited in a small place like a room.<ref name='James'></ref>

After identifying all these impediments Scrum master has the task to eliminate them.

===Backlog Refinement Meeting ===
Especially at the beginning of the project "most of the Product Backlog Items (PBIs) need refinement because they are too large and poorly understood" (''M. James, 2010'')<ref name='James'></ref>. In the Backlog Refinement Meeting, the gives an estimation of the remaining work that is required to complete the Items in the Product Backlog and provides other technical informations in order to help the Product Owner to prioritize them.

==Artefacts==
[[File:Product_Backlog_2.png|350px|thumb|right|Product Backlog and Sprint Backlog<ref name='James'></ref>]]
===Product Backlog===

It is defined before the project beginning and then upgraded during the Backlog Refinement meeting ; it is made up by the whole group of items which have to be completed during the project in order to realize the final product. Every item is ranked and constantly reprioritized by the Product Owner. It is important that Product Backlog is visible to the stakeholders.

===Product Backlog Item (PBI)===
An item specifies what has to be done but not how do it. Usually they are written in a User story to be understood also by stakeholders. Every items has a work load of 2-3 days and requires 2-3 people. It represents the basic unit of the Product backlog.
[[File:Sprint_Backlog.png|200px|thumb|right|Sprint Backlog<ref name='James'></ref>]]
===Sprint backlog===

It is defined at the beginning of each sprint during the Sprint Planning meeting where the committed items and the main task that have to be done during the sprint are identified. It has to be visible to the Scrum team and also upgraded during the sprint execution with the additional tasks necessary to achieve the final goal.

===Sprint task===
Every item is divided into several tasks, each of them requires one day or less of work. A sprint task specifies how to achieve what is required by PBI. If the task takes more than one day of work, remaining effort is re-estimated daily, typically in hours.

===Sprint Burndown Chart===
[[File:Sprint_burndown_chart.png|300px|thumb|right|Sprint Burndown Chart<ref name='James'></ref>]]
This tool is used to facilitate self-organization of the team. It indicates the total remaining team task hours within one Sprint. Usually chart shows a decreasing line but if there are some re-estimation it may be possible that line increase for then going down. As picture shows it has a time line in the x axis and the remaining hours of work within one Sprint in the y axis. The advantage of this tool is to show at a first sight at which point of the project you are and the work that is left to complete the Sprint. It is important that this tool is used only as help to Scrum team; in some situations it could become a constraint for developers, in this case Scrum Master has to remove this chart from the room.

=Limitations=
Scrum method was often used in the object-oriented software development. Actually this technique are applied not only on software but also on other products from different sectors like wheelchairs, semiconductors and mortgages.
Scrum has to be used in those projects where people cannot rely on the plan-driven approaches like Waterfall, because of unknown requirements and technology.
[[File:Graph.png|300px|thumb|right|Predictability of a Project<ref name='James'></ref>]]
Conversely if the projects is placed under precise and stable conditions it is better to use one of the traditional model which allow to have a fixed planning over the whole project. In this case Scrum method would involve in a waste of resources and money because he is working on a field that is not its responsibility.

Michael James in his “Scrum Reference card” explains with a simple graphics in which conditions Scrum should be used and which ones are not. James defines the predictability of the projects on the base of two features: knowledge of the requirements and knowledge of the level of technology required. A project which provides known requirements and a known level of technology should be carried out with a plan-driven model. It these conditions are not met it is better to use an empirical approach like Scrum.<ref name='James'></ref>

=References=
<references/>

Scrum Methodology in Agile Software Development

2015-09-28T21:47:00Z

S150821: /* Team self-organization */

Today market is affected by uncertainly and sudden changes, in these conditions most of the models used in the 20th century to develop software are not still appropriate.[[Wikipedia:Waterfall model | Waterfall model]] , probably the most famous between them, is characterized by a stiff structure which can’t cope with the turbulent needs of the actual market.
In recent years many innovations are been enhanced in software engineering with a particular focus on the flexibility of these methods in order to cope with the customers' and markets' needs; surely [[Wikipedia: Agile Software Development |Agile Software Development (ASD)]] is between them.

ASD embraces the principles of [[Wikipedia:Lean Production|Lean Production]] by applying them in software development to avoid waste and increase responsiveness to change. It represents the solution to the unpredictability of the market where the capacity "to welcome change even late in development" (''K. Beck et all, 2001'')<ref name='Manifesto'></ref> is required.
This article deals with Agile Software Development with a particular focus on one of its most used technique : '''Scrum Methodology'''.

=Scrum Methodology=
Scrum is an iterative method used to develop software, it can be placed inside the group of methods which are used in '''ASD'''. This word is taken from rugby and represents that phase of the match where an ordered formation of players, with arms interlocked and heads down, push forward against a similar group to gain possession of the ball<ref name='Cohen'></ref>. This method provides that "work is divided into small chunks to manage complexity and to get early feedback from customers and end users" (''S. Augustine, 2005'')<ref>S. Augustine,2005,Prentice Hall PTR,Managing Agile Projects</ref>; software development is carried out by small working team that allow rapid adjustment during the process and a quick delivery of the final product.

==Agile Software Development==
At the end of the 20th century there were some practitioners who believed that traditional [[Wikipedia:Iterative model |Iterative model]] was not so responsive to market changes. They defined Agile a process which was able to accept change rather than stress predictability.They also believed that to well face customers’ needs development software methods have to respond to change as quickly as it arose rather than prevent changes.<ref name='Cohen'>D.Cohen,M.Lindval,P. Costa,Fraunhofer Center Maryland, Agile Software Development</ref>

It was in these circumstances that practitioners as Mary Poppendieck and Bob Charet started to take inspiration from Lean manufacturing principles and apply them to software development.
These are the main points ,according to Poppendieck, which make Lean Production so successful and that can be applied to software development:

*elimination of waste that does not add value to the customer such as diagram and models that do not add value to the final deliverable;
*minimize inventory such as requirements and design documents;
*maximize flow by using iterative development to reduce development time;
*pull from demand;
*empower workers that means “tell developer what needs to be done not how to do it";
*meet customer requirements – work closely with the customer, allowing them to change their minds
*do it right the first time – test early and refactor when necessary;
*abolish local optimization – flexibly manage scope;
*partner with suppliers – avoid adversarial relationships, work towards developing the best software;
*create a culture of continuous improvement – allow the process to improve, learn from mistakes and successes.<ref name='Cohen'></ref><ref>M. Poppendieck, T. Poppendieck, 2003, Addison Wesley, Lean Software Development: An Agile Toolkit[[http://www.poppendieck.com/]]</ref>

===Manifesto for the Agile Software development===
A few years before Poppoendieck’s publication, on February 2001,a group of seventeen software developers published in a work called “Manifesto for the Agile Software Development”<ref name='Manifesto'>K. Beck et all., 2001, Manifesto for Agile Software Development[http://www.agilemanifesto.org/]</ref> the main principles of Agile Software development.

From reading these few words it is possible to identify what are the main innovations that ASD introduced in Software development:
[[File:Agilemanifesto.jpg|400px|thumb|right|Manifesto for the Agile Software development<ref name='Manifesto'></ref>]]

*'''“Individuals and interactions”''': with these words founders want to remark the power of human being creativity and also the ability of each man to collaborate with his other similars. The stiffness of Waterfall model is instead represented by “processes and tools” where people was used to follow only what the plan required.
*'''“Working software“''': here there is a clear reference to the new way of developing software where at every iteration a working program is realised. This is different from the previous model in which a working program couldn’t be seen until the end of the project. This feature is put over the “comprehensive documentation” which characterizes especially Waterfall model.
*'''“Customer collaboration”''': it means that there must be a straight relationship between customer and developer in order to define time by time the projects requirements and evaluate every realise.
*'''“Responding to change over following a plan”''' : this sentence encloses the essence of Agile software Development that is to cope with turbulent markets by being flexible and by responding quickly to change. This concept was remarked by the founders in one of the twelve principles which follow the manifesto which says “Welcome changing requirements, even late in development […]”.<ref name='Manifesto'></ref>

=Application=
[[File:Scrum_Framework.png|350px|thumb|right|Scrum Framework]]
There are two concepts that are at the basement of Scrum methodology: '''iterative development''' and '''team working'''. Developing in iterations allow Scrum team to adapt quickly to changing requirements, while working in close location and focusing on communication allow team to make decisions and act on them immediately rather than wait on correspondence.<ref name='Cohen'></ref>

Basically Scrum consists in a sequence of fixed-length iterations called '''Sprint''' that are the fundamental units in which the whole project is divided. As the picture shows Scrum framework is really simple: it starts from a vision like all projects. This idea is converted into a plan during the preliminary meetings where customers and developers identifies the main software requirements and defines the Product Backlog. This represents the entire amount of work that has to be done in order to develop the software. In the next step Product Backlog is divided into several Sprint Backlogs that define which tasks have to be done during the following Sprint. During these iterations the product experiences an incremental development at the end of which it is potentially shippable.

Every Sprint is managed by one or more '''cross-functional and self-organizing teams''' each composed by seven people. There are also other two actors whose task is to be supportive of the software development. One is the '''Product Owner''' who mainly handles customers contacts, and the other is the '''Scrum Master''' whose main task is to ensure that development team can work without obstacles.

Each sprint usually lasts from 2 to 4 weeks, in this period there are at least one meeting between the Product Owner and Development Team in order to define the main objectives; then there are also short daily meetings held every morning to enhance communication, inform customers, developers, and managers on the status of the project, identify any problems encountered, and keep the entire team focused on a common goal.<ref name='Cohen'></ref>

==Main Actors in Scrum==
===Product Owner===
Product owner is the link between customers and development team, he ensures that deliverables are in line with customers’ expectation and that stakeholders’ interests are fulfilled. He has also the task to fill out customer-centric items (typically '''user stories'''), ranks and prioritizes them before adds them to the '''Product Backlog'''.

Usually development teams have only one Product owner, but differently from the Scrum master, he only takes care of the business side and does not interfere with the scrum team about the technological issues. At the beginning of each Sprint the Product Owner holds a Sprint Planning Meeting to state on which Product Backlog Items Scrum team will go to work during the next Sprint. In this phase he defines what are the most important items for that business, in according to the customer’s needs.

===Development Team===
Development team task is to deliver Product Backlog Items (PBIs) at the end of every Sprint in according with customers’ requirements.
Usually each team is composed by '''cross-functional members''' that allow an all-round software development; the main figures that there must be are a mix of software engineers, architects, programmers, analysts, QA experts, testers, and UI designers.

The size of the team is an important point, the group members' number influences capacity of people to communicate and work together: it is recommended that a scrum team is composed not more than nine people, usually seven.

Another peculiarity of Scrum team is its Self-organization which facilitates members’ creativity and increases team cohesiveness. For this reason it is recommended to not change the members of a team after they have worked together, especially if they had success in their project. After working together team members gain a mutual understanding that increases their capacity of team working, this synergy cannot be acquired if team are continuously changed.

A further point that characterized the good outcomes of a scrum team is location: people are most successful when located in the same room, particularly for the first few Sprints, this facilitates communication and information sharing.

====Team self-organization====
Team self-organization is a crucial point in the scrum methodology. This new concept is well explained in the sentence “it is told developer what needs to be done not how to do it”<ref name='Cohen'></ref>. It means that they can autonomously choose the way to reach commitments.
Furthermore, as it is explained previously, during Sprint execution team members develop an intrinsic interest in shared goals, in this way self-organizing teams can radically outperform larger than traditionally managed teams. It has to be specified that an optimal self-organization takes time: it may be possible that for the first few sprints developers perform worse than when they work in the traditional way.

Some requirements are necessary to gain a good team self-organization:
*members are committed to clear, short-term goals;
*members can gauge the group’s progress;
*members can observe each other’s contribution;
*members feel safe to give each other unvarnished feedback.<ref name='James'>M. James,2010,Scrum Reference Card, Michael James,[[http://scrumreferencecard.com/]]</ref>

Conversely there are some conditions that can hamper self-organization:
*geographical distribution: it is better if the whole team work in a room;
*boss/work dynamics: each member has to consider the others as peer to facilitate a fair communication between them;
*part-time team members;
*interruptions unrelated to Sprint goals.

===Scrum Master===
The scrum master worries that Scrum team can work without obstacles but he has no management authority over them. Essentially he has the aim to:
*create an environment to promote team self-organization;
*support team in the achievement of expected goals;
*ensure that events (e.g. daily Scrum meeting) take place in the right way;
*keep '''Scrum artefacts''' visible ('''Product Backlog''', '''Sprint Backlog''', '''Sprint burndown chart''' …).

==Sprint==
As it is already explained before Sprint (or iteration) is the fundamental unit in which the whole project is divided. It is characterized by a fixed length of 2 weeks or 30 days and by a goal to achieve. At the beginning of each sprint Scrum team , Product Owner , Scrum Master and sometimes also stakeholders hold a meeting, called Sprint Planning meeting. During this encounter it is defined the Sprint Backlog which states what are the goals and requirements of the next Sprint. After this further meetings inside development team will be held in order to define in more detail how achieving the common goals stated in the previous meetings.
==Scrum Meetings==
[[File:Scrum_meetings.png|350px|thumb|right|Scrum Meetings<ref name='James'></ref>]]
Meetings are the fundamental tool used during the whole Scrum process. Usually they are facilitated by the Scrum master who however has no decision-making authority over them. There are different typologies of meetings according to the different phase of the process in which we are.
===Sprint Planning Meeting===
At the beginning of each Sprint, the Product Owner and team hold a Sprint Planning Meeting to define on which '''Product Backlog Items (PBIs)''' they will go to work during the next Sprint. During this meeting "The Product Owner is responsible for declaring which items are the most important to the business" instead "the team is responsible for selecting the amount of work they feel they can implement" (''M. James, 2010'')<ref name='James'></ref>.In this phase in perfect Lean perspective the team “pulls” work from the Product Backlog to the Sprint Backlog. At the end of the meeting the selected items are broken into a provisional list of Sprint task. The maximum time that can be used to do Planning meeting, known as '''timebox''', is of eight hours.

===Daily Scrum and Sprint Execution===
During the sprint every day members of the Scrum team hold a fifteen minutes meeting where they take stock of the situation. Usually they speak about what they did the previous day, which impediments they faced and what they are going to do in the current day. To make these meetings shorter it is better that people are standing.
During sprint execution it is common to find out additional tasks necessary to achieve sprint goal; to keep the control over processes during sprint development it could be useful to maintain a current '''Sprint Task List''', a '''Sprint Burndown Chart''', and an '''Impediments List''': these are some artefacts that allow developer to understand where the project is located.

===Sprint Review Meeting===
At the end of every Sprint it is held a Review meeting where the scrum team has to explain to the Product Owner what they did during the previous sprint. Usually this meeting consists in a live demonstration of the working product increment after which Product Owner states which Items can be considered as done.
Items which are declared not done have to return to the Product Backlog to be ranked and reprioritized by the Product Owner with the help of the Scrum master. Last step of this meeting is to convert stakeholders’ feedback to a new Product Log, this task is consigned to both Product Owner and Scrum Master.
The Sprint Review Meeting is the appropriate meeting for external stakeholders (even end users) to attend.

===Sprint Retrospective Meeting===
During this meeting every member of the scrum team inspects his behaviour to identify some impediments that he faced during the Sprint. There are mainly three kind of impediments in which developers can be involved:
*people who conduct performance evaluation are an obstacles to transparency of the team;
*human tendency of someone in the team to jump to conclusions and propose actions too quickly;
*geographical distribution of the team can be an impediments, team work better if they are delimited in a small place like a room.<ref name='James'></ref>

After identifying all these impediments Scrum master has the task to eliminate them.

===Backlog Refinement Meeting ===
Especially at the beginning of the project "most of the Product Backlog Items (PBIs) need refinement because they are too large and poorly understood" (''M. James, 2010'')<ref name='James'></ref>. In the Backlog Refinement Meeting, the gives an estimation of the remaining work that is required to complete the Items in the Product Backlog and provides other technical informations in order to help the Product Owner to prioritize them.

==Artefacts==
[[File:Product_Backlog_2.png|350px|thumb|right|Product Backlog and Sprint Backlog<ref name='James'></ref>]]
===Product Backlog===

It is defined before the project beginning and then upgraded during the Backlog Refinement meeting ; it is made up by the whole group of items which have to be completed during the project in order to realize the final product. Every item is ranked and constantly reprioritized by the Product Owner. It is important that Product Backlog is visible to the stakeholders.

===Product Backlog Item (PBI)===
An item specifies what has to be done but not how do it. Usually they are written in a User story to be understood also by stakeholders. Every items has a work load of 2-3 days and requires 2-3 people. It represents the basic unit of the Product backlog.
[[File:Sprint_Backlog.png|200px|thumb|right|Sprint Backlog<ref name='James'></ref>]]
===Sprint backlog===

It is defined at the beginning of each sprint during the Sprint Planning meeting where the committed items and the main task that have to be done during the sprint are identified. It has to be visible to the Scrum team and also upgraded during the sprint execution with the additional tasks necessary to achieve the final goal.

===Sprint task===
Every item is divided into several tasks, each of them requires one day or less of work. A sprint task specifies how to achieve what is required by PBI. If the task takes more than one day of work, remaining effort is re-estimated daily, typically in hours.

===Sprint Burndown Chart===
[[File:Sprint_burndown_chart.png|300px|thumb|right|Sprint Burndown Chart<ref name='James'></ref>]]
This tool is used to facilitate self-organization of the team. It indicates the total remaining team task hours within one Sprint. Usually chart shows a decreasing line but if there are some re-estimation it may be possible that line increase for then going down. As picture shows it has a time line in the x axis and the remaining hours of work within one Sprint in the y axis. The advantage of this tool is to show at a first sight at which point of the project you are and the work that is left to complete the Sprint. It is important that this tool is used only as help to Scrum team; in some situations it could become a constraint for developers, in this case Scrum Master has to remove this chart from the room.

=Limitations=
Scrum method was often used in the object-oriented software development. Actually this technique are applied not only on software but also on other products from different sectors like wheelchairs, semiconductors and mortgages.
Scrum has to be used in those projects where people cannot rely on the plan-driven approaches like Waterfall, because of unknown requirements and technology.
[[File:Graph.png|300px|thumb|right|Predictability of a Project<ref name='James'></ref>]]
Conversely if the projects is placed under precise and stable conditions it is better to use one of the traditional model which allow to have a fixed planning over the whole project. In this case Scrum method would involve in a waste of resources and money because he is working on a field that is not its responsibility.

Michael James in his “Scrum Reference card” explains with a simple graphics in which conditions Scrum should be used and which ones are not. James defines the predictability of the projects on the base of two features: knowledge of the requirements and knowledge of the level of technology required. A project which provides known requirements and a known level of technology should be carried out with a plan-driven model. It these conditions are not met it is better to use an empirical approach like Scrum.<ref name='James'></ref>

=References=
<references/>

Scrum Methodology in Agile Software Development

2015-09-28T21:46:17Z

S150821: /* Team self-organization */

Today market is affected by uncertainly and sudden changes, in these conditions most of the models used in the 20th century to develop software are not still appropriate.[[Wikipedia:Waterfall model | Waterfall model]] , probably the most famous between them, is characterized by a stiff structure which can’t cope with the turbulent needs of the actual market.
In recent years many innovations are been enhanced in software engineering with a particular focus on the flexibility of these methods in order to cope with the customers' and markets' needs; surely [[Wikipedia: Agile Software Development |Agile Software Development (ASD)]] is between them.

ASD embraces the principles of [[Wikipedia:Lean Production|Lean Production]] by applying them in software development to avoid waste and increase responsiveness to change. It represents the solution to the unpredictability of the market where the capacity "to welcome change even late in development" (''K. Beck et all, 2001'')<ref name='Manifesto'></ref> is required.
This article deals with Agile Software Development with a particular focus on one of its most used technique : '''Scrum Methodology'''.

=Scrum Methodology=
Scrum is an iterative method used to develop software, it can be placed inside the group of methods which are used in '''ASD'''. This word is taken from rugby and represents that phase of the match where an ordered formation of players, with arms interlocked and heads down, push forward against a similar group to gain possession of the ball<ref name='Cohen'></ref>. This method provides that "work is divided into small chunks to manage complexity and to get early feedback from customers and end users" (''S. Augustine, 2005'')<ref>S. Augustine,2005,Prentice Hall PTR,Managing Agile Projects</ref>; software development is carried out by small working team that allow rapid adjustment during the process and a quick delivery of the final product.

==Agile Software Development==
At the end of the 20th century there were some practitioners who believed that traditional [[Wikipedia:Iterative model |Iterative model]] was not so responsive to market changes. They defined Agile a process which was able to accept change rather than stress predictability.They also believed that to well face customers’ needs development software methods have to respond to change as quickly as it arose rather than prevent changes.<ref name='Cohen'>D.Cohen,M.Lindval,P. Costa,Fraunhofer Center Maryland, Agile Software Development</ref>

It was in these circumstances that practitioners as Mary Poppendieck and Bob Charet started to take inspiration from Lean manufacturing principles and apply them to software development.
These are the main points ,according to Poppendieck, which make Lean Production so successful and that can be applied to software development:

*elimination of waste that does not add value to the customer such as diagram and models that do not add value to the final deliverable;
*minimize inventory such as requirements and design documents;
*maximize flow by using iterative development to reduce development time;
*pull from demand;
*empower workers that means “tell developer what needs to be done not how to do it";
*meet customer requirements – work closely with the customer, allowing them to change their minds
*do it right the first time – test early and refactor when necessary;
*abolish local optimization – flexibly manage scope;
*partner with suppliers – avoid adversarial relationships, work towards developing the best software;
*create a culture of continuous improvement – allow the process to improve, learn from mistakes and successes.<ref name='Cohen'></ref><ref>M. Poppendieck, T. Poppendieck, 2003, Addison Wesley, Lean Software Development: An Agile Toolkit[[http://www.poppendieck.com/]]</ref>

===Manifesto for the Agile Software development===
A few years before Poppoendieck’s publication, on February 2001,a group of seventeen software developers published in a work called “Manifesto for the Agile Software Development”<ref name='Manifesto'>K. Beck et all., 2001, Manifesto for Agile Software Development[http://www.agilemanifesto.org/]</ref> the main principles of Agile Software development.

From reading these few words it is possible to identify what are the main innovations that ASD introduced in Software development:
[[File:Agilemanifesto.jpg|400px|thumb|right|Manifesto for the Agile Software development<ref name='Manifesto'></ref>]]

*'''“Individuals and interactions”''': with these words founders want to remark the power of human being creativity and also the ability of each man to collaborate with his other similars. The stiffness of Waterfall model is instead represented by “processes and tools” where people was used to follow only what the plan required.
*'''“Working software“''': here there is a clear reference to the new way of developing software where at every iteration a working program is realised. This is different from the previous model in which a working program couldn’t be seen until the end of the project. This feature is put over the “comprehensive documentation” which characterizes especially Waterfall model.
*'''“Customer collaboration”''': it means that there must be a straight relationship between customer and developer in order to define time by time the projects requirements and evaluate every realise.
*'''“Responding to change over following a plan”''' : this sentence encloses the essence of Agile software Development that is to cope with turbulent markets by being flexible and by responding quickly to change. This concept was remarked by the founders in one of the twelve principles which follow the manifesto which says “Welcome changing requirements, even late in development […]”.<ref name='Manifesto'></ref>

=Application=
[[File:Scrum_Framework.png|350px|thumb|right|Scrum Framework]]
There are two concepts that are at the basement of Scrum methodology: '''iterative development''' and '''team working'''. Developing in iterations allow Scrum team to adapt quickly to changing requirements, while working in close location and focusing on communication allow team to make decisions and act on them immediately rather than wait on correspondence.<ref name='Cohen'></ref>

Basically Scrum consists in a sequence of fixed-length iterations called '''Sprint''' that are the fundamental units in which the whole project is divided. As the picture shows Scrum framework is really simple: it starts from a vision like all projects. This idea is converted into a plan during the preliminary meetings where customers and developers identifies the main software requirements and defines the Product Backlog. This represents the entire amount of work that has to be done in order to develop the software. In the next step Product Backlog is divided into several Sprint Backlogs that define which tasks have to be done during the following Sprint. During these iterations the product experiences an incremental development at the end of which it is potentially shippable.

Every Sprint is managed by one or more '''cross-functional and self-organizing teams''' each composed by seven people. There are also other two actors whose task is to be supportive of the software development. One is the '''Product Owner''' who mainly handles customers contacts, and the other is the '''Scrum Master''' whose main task is to ensure that development team can work without obstacles.

Each sprint usually lasts from 2 to 4 weeks, in this period there are at least one meeting between the Product Owner and Development Team in order to define the main objectives; then there are also short daily meetings held every morning to enhance communication, inform customers, developers, and managers on the status of the project, identify any problems encountered, and keep the entire team focused on a common goal.<ref name='Cohen'></ref>

==Main Actors in Scrum==
===Product Owner===
Product owner is the link between customers and development team, he ensures that deliverables are in line with customers’ expectation and that stakeholders’ interests are fulfilled. He has also the task to fill out customer-centric items (typically '''user stories'''), ranks and prioritizes them before adds them to the '''Product Backlog'''.

Usually development teams have only one Product owner, but differently from the Scrum master, he only takes care of the business side and does not interfere with the scrum team about the technological issues. At the beginning of each Sprint the Product Owner holds a Sprint Planning Meeting to state on which Product Backlog Items Scrum team will go to work during the next Sprint. In this phase he defines what are the most important items for that business, in according to the customer’s needs.

===Development Team===
Development team task is to deliver Product Backlog Items (PBIs) at the end of every Sprint in according with customers’ requirements.
Usually each team is composed by '''cross-functional members''' that allow an all-round software development; the main figures that there must be are a mix of software engineers, architects, programmers, analysts, QA experts, testers, and UI designers.

The size of the team is an important point, the group members' number influences capacity of people to communicate and work together: it is recommended that a scrum team is composed not more than nine people, usually seven.

Another peculiarity of Scrum team is its Self-organization which facilitates members’ creativity and increases team cohesiveness. For this reason it is recommended to not change the members of a team after they have worked together, especially if they had success in their project. After working together team members gain a mutual understanding that increases their capacity of team working, this synergy cannot be acquired if team are continuously changed.

A further point that characterized the good outcomes of a scrum team is location: people are most successful when located in the same room, particularly for the first few Sprints, this facilitates communication and information sharing.

====Team self-organization====
Team self-organization is a crucial point in the scrum methodology. This new concept is well explained in the sentence “it is told developer what needs to be done not how to do it”<ref name='Cohen'></ref>. It means that they can autonomously choose the way to reach commitments.
Furthermore, as it is explained previously, during Sprint execution team members develop an intrinsic interest in shared goals in this way self-organizing teams can radically outperform larger than traditionally managed teams. It has to be specified that an optimal self-organization takes time: it may be possible that for the first few sprints developers perform worse than when they work in the traditional way.

Some requirements are necessary to gain a good team self-organization:
*members are committed to clear, short-term goals;
*members can gauge the group’s progress;
*members can observe each other’s contribution;
*members feel safe to give each other unvarnished feedback.<ref name='James'>M. James,2010,Scrum Reference Card, Michael James,[[http://scrumreferencecard.com/]]</ref>

Conversely there are some conditions that can hamper self-organization:
*geographical distribution: it is better if the whole team work in a room;
*boss/work dynamics: each member has to consider the others as peer to facilitate a fair communication between them;
*part-time team members;
*interruptions unrelated to Sprint goals.

===Scrum Master===
The scrum master worries that Scrum team can work without obstacles but he has no management authority over them. Essentially he has the aim to:
*create an environment to promote team self-organization;
*support team in the achievement of expected goals;
*ensure that events (e.g. daily Scrum meeting) take place in the right way;
*keep '''Scrum artefacts''' visible ('''Product Backlog''', '''Sprint Backlog''', '''Sprint burndown chart''' …).

==Sprint==
As it is already explained before Sprint (or iteration) is the fundamental unit in which the whole project is divided. It is characterized by a fixed length of 2 weeks or 30 days and by a goal to achieve. At the beginning of each sprint Scrum team , Product Owner , Scrum Master and sometimes also stakeholders hold a meeting, called Sprint Planning meeting. During this encounter it is defined the Sprint Backlog which states what are the goals and requirements of the next Sprint. After this further meetings inside development team will be held in order to define in more detail how achieving the common goals stated in the previous meetings.
==Scrum Meetings==
[[File:Scrum_meetings.png|350px|thumb|right|Scrum Meetings<ref name='James'></ref>]]
Meetings are the fundamental tool used during the whole Scrum process. Usually they are facilitated by the Scrum master who however has no decision-making authority over them. There are different typologies of meetings according to the different phase of the process in which we are.
===Sprint Planning Meeting===
At the beginning of each Sprint, the Product Owner and team hold a Sprint Planning Meeting to define on which '''Product Backlog Items (PBIs)''' they will go to work during the next Sprint. During this meeting "The Product Owner is responsible for declaring which items are the most important to the business" instead "the team is responsible for selecting the amount of work they feel they can implement" (''M. James, 2010'')<ref name='James'></ref>.In this phase in perfect Lean perspective the team “pulls” work from the Product Backlog to the Sprint Backlog. At the end of the meeting the selected items are broken into a provisional list of Sprint task. The maximum time that can be used to do Planning meeting, known as '''timebox''', is of eight hours.

===Daily Scrum and Sprint Execution===
During the sprint every day members of the Scrum team hold a fifteen minutes meeting where they take stock of the situation. Usually they speak about what they did the previous day, which impediments they faced and what they are going to do in the current day. To make these meetings shorter it is better that people are standing.
During sprint execution it is common to find out additional tasks necessary to achieve sprint goal; to keep the control over processes during sprint development it could be useful to maintain a current '''Sprint Task List''', a '''Sprint Burndown Chart''', and an '''Impediments List''': these are some artefacts that allow developer to understand where the project is located.

===Sprint Review Meeting===
At the end of every Sprint it is held a Review meeting where the scrum team has to explain to the Product Owner what they did during the previous sprint. Usually this meeting consists in a live demonstration of the working product increment after which Product Owner states which Items can be considered as done.
Items which are declared not done have to return to the Product Backlog to be ranked and reprioritized by the Product Owner with the help of the Scrum master. Last step of this meeting is to convert stakeholders’ feedback to a new Product Log, this task is consigned to both Product Owner and Scrum Master.
The Sprint Review Meeting is the appropriate meeting for external stakeholders (even end users) to attend.

===Sprint Retrospective Meeting===
During this meeting every member of the scrum team inspects his behaviour to identify some impediments that he faced during the Sprint. There are mainly three kind of impediments in which developers can be involved:
*people who conduct performance evaluation are an obstacles to transparency of the team;
*human tendency of someone in the team to jump to conclusions and propose actions too quickly;
*geographical distribution of the team can be an impediments, team work better if they are delimited in a small place like a room.<ref name='James'></ref>

After identifying all these impediments Scrum master has the task to eliminate them.

===Backlog Refinement Meeting ===
Especially at the beginning of the project "most of the Product Backlog Items (PBIs) need refinement because they are too large and poorly understood" (''M. James, 2010'')<ref name='James'></ref>. In the Backlog Refinement Meeting, the gives an estimation of the remaining work that is required to complete the Items in the Product Backlog and provides other technical informations in order to help the Product Owner to prioritize them.

==Artefacts==
[[File:Product_Backlog_2.png|350px|thumb|right|Product Backlog and Sprint Backlog<ref name='James'></ref>]]
===Product Backlog===

It is defined before the project beginning and then upgraded during the Backlog Refinement meeting ; it is made up by the whole group of items which have to be completed during the project in order to realize the final product. Every item is ranked and constantly reprioritized by the Product Owner. It is important that Product Backlog is visible to the stakeholders.

===Product Backlog Item (PBI)===
An item specifies what has to be done but not how do it. Usually they are written in a User story to be understood also by stakeholders. Every items has a work load of 2-3 days and requires 2-3 people. It represents the basic unit of the Product backlog.
[[File:Sprint_Backlog.png|200px|thumb|right|Sprint Backlog<ref name='James'></ref>]]
===Sprint backlog===

It is defined at the beginning of each sprint during the Sprint Planning meeting where the committed items and the main task that have to be done during the sprint are identified. It has to be visible to the Scrum team and also upgraded during the sprint execution with the additional tasks necessary to achieve the final goal.

===Sprint task===
Every item is divided into several tasks, each of them requires one day or less of work. A sprint task specifies how to achieve what is required by PBI. If the task takes more than one day of work, remaining effort is re-estimated daily, typically in hours.

===Sprint Burndown Chart===
[[File:Sprint_burndown_chart.png|300px|thumb|right|Sprint Burndown Chart<ref name='James'></ref>]]
This tool is used to facilitate self-organization of the team. It indicates the total remaining team task hours within one Sprint. Usually chart shows a decreasing line but if there are some re-estimation it may be possible that line increase for then going down. As picture shows it has a time line in the x axis and the remaining hours of work within one Sprint in the y axis. The advantage of this tool is to show at a first sight at which point of the project you are and the work that is left to complete the Sprint. It is important that this tool is used only as help to Scrum team; in some situations it could become a constraint for developers, in this case Scrum Master has to remove this chart from the room.

=Limitations=
Scrum method was often used in the object-oriented software development. Actually this technique are applied not only on software but also on other products from different sectors like wheelchairs, semiconductors and mortgages.
Scrum has to be used in those projects where people cannot rely on the plan-driven approaches like Waterfall, because of unknown requirements and technology.
[[File:Graph.png|300px|thumb|right|Predictability of a Project<ref name='James'></ref>]]
Conversely if the projects is placed under precise and stable conditions it is better to use one of the traditional model which allow to have a fixed planning over the whole project. In this case Scrum method would involve in a waste of resources and money because he is working on a field that is not its responsibility.

Michael James in his “Scrum Reference card” explains with a simple graphics in which conditions Scrum should be used and which ones are not. James defines the predictability of the projects on the base of two features: knowledge of the requirements and knowledge of the level of technology required. A project which provides known requirements and a known level of technology should be carried out with a plan-driven model. It these conditions are not met it is better to use an empirical approach like Scrum.<ref name='James'></ref>

=References=
<references/>

Scrum Methodology in Agile Software Development

2015-09-28T21:45:30Z

S150821: /* Team self-organization */

Today market is affected by uncertainly and sudden changes, in these conditions most of the models used in the 20th century to develop software are not still appropriate.[[Wikipedia:Waterfall model | Waterfall model]] , probably the most famous between them, is characterized by a stiff structure which can’t cope with the turbulent needs of the actual market.
In recent years many innovations are been enhanced in software engineering with a particular focus on the flexibility of these methods in order to cope with the customers' and markets' needs; surely [[Wikipedia: Agile Software Development |Agile Software Development (ASD)]] is between them.

ASD embraces the principles of [[Wikipedia:Lean Production|Lean Production]] by applying them in software development to avoid waste and increase responsiveness to change. It represents the solution to the unpredictability of the market where the capacity "to welcome change even late in development" (''K. Beck et all, 2001'')<ref name='Manifesto'></ref> is required.
This article deals with Agile Software Development with a particular focus on one of its most used technique : '''Scrum Methodology'''.

=Scrum Methodology=
Scrum is an iterative method used to develop software, it can be placed inside the group of methods which are used in '''ASD'''. This word is taken from rugby and represents that phase of the match where an ordered formation of players, with arms interlocked and heads down, push forward against a similar group to gain possession of the ball<ref name='Cohen'></ref>. This method provides that "work is divided into small chunks to manage complexity and to get early feedback from customers and end users" (''S. Augustine, 2005'')<ref>S. Augustine,2005,Prentice Hall PTR,Managing Agile Projects</ref>; software development is carried out by small working team that allow rapid adjustment during the process and a quick delivery of the final product.

==Agile Software Development==
At the end of the 20th century there were some practitioners who believed that traditional [[Wikipedia:Iterative model |Iterative model]] was not so responsive to market changes. They defined Agile a process which was able to accept change rather than stress predictability.They also believed that to well face customers’ needs development software methods have to respond to change as quickly as it arose rather than prevent changes.<ref name='Cohen'>D.Cohen,M.Lindval,P. Costa,Fraunhofer Center Maryland, Agile Software Development</ref>

It was in these circumstances that practitioners as Mary Poppendieck and Bob Charet started to take inspiration from Lean manufacturing principles and apply them to software development.
These are the main points ,according to Poppendieck, which make Lean Production so successful and that can be applied to software development:

*elimination of waste that does not add value to the customer such as diagram and models that do not add value to the final deliverable;
*minimize inventory such as requirements and design documents;
*maximize flow by using iterative development to reduce development time;
*pull from demand;
*empower workers that means “tell developer what needs to be done not how to do it";
*meet customer requirements – work closely with the customer, allowing them to change their minds
*do it right the first time – test early and refactor when necessary;
*abolish local optimization – flexibly manage scope;
*partner with suppliers – avoid adversarial relationships, work towards developing the best software;
*create a culture of continuous improvement – allow the process to improve, learn from mistakes and successes.<ref name='Cohen'></ref><ref>M. Poppendieck, T. Poppendieck, 2003, Addison Wesley, Lean Software Development: An Agile Toolkit[[http://www.poppendieck.com/]]</ref>

===Manifesto for the Agile Software development===
A few years before Poppoendieck’s publication, on February 2001,a group of seventeen software developers published in a work called “Manifesto for the Agile Software Development”<ref name='Manifesto'>K. Beck et all., 2001, Manifesto for Agile Software Development[http://www.agilemanifesto.org/]</ref> the main principles of Agile Software development.

From reading these few words it is possible to identify what are the main innovations that ASD introduced in Software development:
[[File:Agilemanifesto.jpg|400px|thumb|right|Manifesto for the Agile Software development<ref name='Manifesto'></ref>]]

*'''“Individuals and interactions”''': with these words founders want to remark the power of human being creativity and also the ability of each man to collaborate with his other similars. The stiffness of Waterfall model is instead represented by “processes and tools” where people was used to follow only what the plan required.
*'''“Working software“''': here there is a clear reference to the new way of developing software where at every iteration a working program is realised. This is different from the previous model in which a working program couldn’t be seen until the end of the project. This feature is put over the “comprehensive documentation” which characterizes especially Waterfall model.
*'''“Customer collaboration”''': it means that there must be a straight relationship between customer and developer in order to define time by time the projects requirements and evaluate every realise.
*'''“Responding to change over following a plan”''' : this sentence encloses the essence of Agile software Development that is to cope with turbulent markets by being flexible and by responding quickly to change. This concept was remarked by the founders in one of the twelve principles which follow the manifesto which says “Welcome changing requirements, even late in development […]”.<ref name='Manifesto'></ref>

=Application=
[[File:Scrum_Framework.png|350px|thumb|right|Scrum Framework]]
There are two concepts that are at the basement of Scrum methodology: '''iterative development''' and '''team working'''. Developing in iterations allow Scrum team to adapt quickly to changing requirements, while working in close location and focusing on communication allow team to make decisions and act on them immediately rather than wait on correspondence.<ref name='Cohen'></ref>

Basically Scrum consists in a sequence of fixed-length iterations called '''Sprint''' that are the fundamental units in which the whole project is divided. As the picture shows Scrum framework is really simple: it starts from a vision like all projects. This idea is converted into a plan during the preliminary meetings where customers and developers identifies the main software requirements and defines the Product Backlog. This represents the entire amount of work that has to be done in order to develop the software. In the next step Product Backlog is divided into several Sprint Backlogs that define which tasks have to be done during the following Sprint. During these iterations the product experiences an incremental development at the end of which it is potentially shippable.

Every Sprint is managed by one or more '''cross-functional and self-organizing teams''' each composed by seven people. There are also other two actors whose task is to be supportive of the software development. One is the '''Product Owner''' who mainly handles customers contacts, and the other is the '''Scrum Master''' whose main task is to ensure that development team can work without obstacles.

Each sprint usually lasts from 2 to 4 weeks, in this period there are at least one meeting between the Product Owner and Development Team in order to define the main objectives; then there are also short daily meetings held every morning to enhance communication, inform customers, developers, and managers on the status of the project, identify any problems encountered, and keep the entire team focused on a common goal.<ref name='Cohen'></ref>

==Main Actors in Scrum==
===Product Owner===
Product owner is the link between customers and development team, he ensures that deliverables are in line with customers’ expectation and that stakeholders’ interests are fulfilled. He has also the task to fill out customer-centric items (typically '''user stories'''), ranks and prioritizes them before adds them to the '''Product Backlog'''.

Usually development teams have only one Product owner, but differently from the Scrum master, he only takes care of the business side and does not interfere with the scrum team about the technological issues. At the beginning of each Sprint the Product Owner holds a Sprint Planning Meeting to state on which Product Backlog Items Scrum team will go to work during the next Sprint. In this phase he defines what are the most important items for that business, in according to the customer’s needs.

===Development Team===
Development team task is to deliver Product Backlog Items (PBIs) at the end of every Sprint in according with customers’ requirements.
Usually each team is composed by '''cross-functional members''' that allow an all-round software development; the main figures that there must be are a mix of software engineers, architects, programmers, analysts, QA experts, testers, and UI designers.

The size of the team is an important point, the group members' number influences capacity of people to communicate and work together: it is recommended that a scrum team is composed not more than nine people, usually seven.

Another peculiarity of Scrum team is its Self-organization which facilitates members’ creativity and increases team cohesiveness. For this reason it is recommended to not change the members of a team after they have worked together, especially if they had success in their project. After working together team members gain a mutual understanding that increases their capacity of team working, this synergy cannot be acquired if team are continuously changed.

A further point that characterized the good outcomes of a scrum team is location: people are most successful when located in the same room, particularly for the first few Sprints, this facilitates communication and information sharing.

====Team self-organization====
Team self-organization is a crucial point in the scrum methodology. This new concept is well explained in the sentence “it is told developer what needs to be done not how to do it”<ref name='Cohen'></ref>. It means that they can autonomously choose the way to reach commitments.
Furthermore, as it is explained previously, during Sprint execution, team members develop an intrinsic interest in shared goals in this way self-organizing teams can radically outperform larger than traditionally managed teams. It has to be specified that an optimal self-organization takes time: it may be possible that for the first few sprints developers perform worse than when they work in the traditional way.

Some requirements are necessary to gain a good team self-organization:
*members are committed to clear, short-term goals;
*members can gauge the group’s progress;
*members can observe each other’s contribution;
*members feel safe to give each other unvarnished feedback.<ref name='James'>M. James,2010,Scrum Reference Card, Michael James,[[http://scrumreferencecard.com/]]</ref>

Conversely there are some conditions that can hamper self-organization:
*geographical distribution: it is better if the whole team work in a room;
*boss/work dynamics: each member has to consider the others as peer to facilitate a fair communication between them;
*part-time team members;
*interruptions unrelated to Sprint goals.

===Scrum Master===
The scrum master worries that Scrum team can work without obstacles but he has no management authority over them. Essentially he has the aim to:
*create an environment to promote team self-organization;
*support team in the achievement of expected goals;
*ensure that events (e.g. daily Scrum meeting) take place in the right way;
*keep '''Scrum artefacts''' visible ('''Product Backlog''', '''Sprint Backlog''', '''Sprint burndown chart''' …).

==Sprint==
As it is already explained before Sprint (or iteration) is the fundamental unit in which the whole project is divided. It is characterized by a fixed length of 2 weeks or 30 days and by a goal to achieve. At the beginning of each sprint Scrum team , Product Owner , Scrum Master and sometimes also stakeholders hold a meeting, called Sprint Planning meeting. During this encounter it is defined the Sprint Backlog which states what are the goals and requirements of the next Sprint. After this further meetings inside development team will be held in order to define in more detail how achieving the common goals stated in the previous meetings.
==Scrum Meetings==
[[File:Scrum_meetings.png|350px|thumb|right|Scrum Meetings<ref name='James'></ref>]]
Meetings are the fundamental tool used during the whole Scrum process. Usually they are facilitated by the Scrum master who however has no decision-making authority over them. There are different typologies of meetings according to the different phase of the process in which we are.
===Sprint Planning Meeting===
At the beginning of each Sprint, the Product Owner and team hold a Sprint Planning Meeting to define on which '''Product Backlog Items (PBIs)''' they will go to work during the next Sprint. During this meeting "The Product Owner is responsible for declaring which items are the most important to the business" instead "the team is responsible for selecting the amount of work they feel they can implement" (''M. James, 2010'')<ref name='James'></ref>.In this phase in perfect Lean perspective the team “pulls” work from the Product Backlog to the Sprint Backlog. At the end of the meeting the selected items are broken into a provisional list of Sprint task. The maximum time that can be used to do Planning meeting, known as '''timebox''', is of eight hours.

===Daily Scrum and Sprint Execution===
During the sprint every day members of the Scrum team hold a fifteen minutes meeting where they take stock of the situation. Usually they speak about what they did the previous day, which impediments they faced and what they are going to do in the current day. To make these meetings shorter it is better that people are standing.
During sprint execution it is common to find out additional tasks necessary to achieve sprint goal; to keep the control over processes during sprint development it could be useful to maintain a current '''Sprint Task List''', a '''Sprint Burndown Chart''', and an '''Impediments List''': these are some artefacts that allow developer to understand where the project is located.

===Sprint Review Meeting===
At the end of every Sprint it is held a Review meeting where the scrum team has to explain to the Product Owner what they did during the previous sprint. Usually this meeting consists in a live demonstration of the working product increment after which Product Owner states which Items can be considered as done.
Items which are declared not done have to return to the Product Backlog to be ranked and reprioritized by the Product Owner with the help of the Scrum master. Last step of this meeting is to convert stakeholders’ feedback to a new Product Log, this task is consigned to both Product Owner and Scrum Master.
The Sprint Review Meeting is the appropriate meeting for external stakeholders (even end users) to attend.

===Sprint Retrospective Meeting===
During this meeting every member of the scrum team inspects his behaviour to identify some impediments that he faced during the Sprint. There are mainly three kind of impediments in which developers can be involved:
*people who conduct performance evaluation are an obstacles to transparency of the team;
*human tendency of someone in the team to jump to conclusions and propose actions too quickly;
*geographical distribution of the team can be an impediments, team work better if they are delimited in a small place like a room.<ref name='James'></ref>

After identifying all these impediments Scrum master has the task to eliminate them.

===Backlog Refinement Meeting ===
Especially at the beginning of the project "most of the Product Backlog Items (PBIs) need refinement because they are too large and poorly understood" (''M. James, 2010'')<ref name='James'></ref>. In the Backlog Refinement Meeting, the gives an estimation of the remaining work that is required to complete the Items in the Product Backlog and provides other technical informations in order to help the Product Owner to prioritize them.

==Artefacts==
[[File:Product_Backlog_2.png|350px|thumb|right|Product Backlog and Sprint Backlog<ref name='James'></ref>]]
===Product Backlog===

It is defined before the project beginning and then upgraded during the Backlog Refinement meeting ; it is made up by the whole group of items which have to be completed during the project in order to realize the final product. Every item is ranked and constantly reprioritized by the Product Owner. It is important that Product Backlog is visible to the stakeholders.

===Product Backlog Item (PBI)===
An item specifies what has to be done but not how do it. Usually they are written in a User story to be understood also by stakeholders. Every items has a work load of 2-3 days and requires 2-3 people. It represents the basic unit of the Product backlog.
[[File:Sprint_Backlog.png|200px|thumb|right|Sprint Backlog<ref name='James'></ref>]]
===Sprint backlog===

It is defined at the beginning of each sprint during the Sprint Planning meeting where the committed items and the main task that have to be done during the sprint are identified. It has to be visible to the Scrum team and also upgraded during the sprint execution with the additional tasks necessary to achieve the final goal.

===Sprint task===
Every item is divided into several tasks, each of them requires one day or less of work. A sprint task specifies how to achieve what is required by PBI. If the task takes more than one day of work, remaining effort is re-estimated daily, typically in hours.

===Sprint Burndown Chart===
[[File:Sprint_burndown_chart.png|300px|thumb|right|Sprint Burndown Chart<ref name='James'></ref>]]
This tool is used to facilitate self-organization of the team. It indicates the total remaining team task hours within one Sprint. Usually chart shows a decreasing line but if there are some re-estimation it may be possible that line increase for then going down. As picture shows it has a time line in the x axis and the remaining hours of work within one Sprint in the y axis. The advantage of this tool is to show at a first sight at which point of the project you are and the work that is left to complete the Sprint. It is important that this tool is used only as help to Scrum team; in some situations it could become a constraint for developers, in this case Scrum Master has to remove this chart from the room.

=Limitations=
Scrum method was often used in the object-oriented software development. Actually this technique are applied not only on software but also on other products from different sectors like wheelchairs, semiconductors and mortgages.
Scrum has to be used in those projects where people cannot rely on the plan-driven approaches like Waterfall, because of unknown requirements and technology.
[[File:Graph.png|300px|thumb|right|Predictability of a Project<ref name='James'></ref>]]
Conversely if the projects is placed under precise and stable conditions it is better to use one of the traditional model which allow to have a fixed planning over the whole project. In this case Scrum method would involve in a waste of resources and money because he is working on a field that is not its responsibility.

Michael James in his “Scrum Reference card” explains with a simple graphics in which conditions Scrum should be used and which ones are not. James defines the predictability of the projects on the base of two features: knowledge of the requirements and knowledge of the level of technology required. A project which provides known requirements and a known level of technology should be carried out with a plan-driven model. It these conditions are not met it is better to use an empirical approach like Scrum.<ref name='James'></ref>

=References=
<references/>

Scrum Methodology in Agile Software Development

2015-09-28T21:44:17Z

S150821: /* Development Team */

Today market is affected by uncertainly and sudden changes, in these conditions most of the models used in the 20th century to develop software are not still appropriate.[[Wikipedia:Waterfall model | Waterfall model]] , probably the most famous between them, is characterized by a stiff structure which can’t cope with the turbulent needs of the actual market.
In recent years many innovations are been enhanced in software engineering with a particular focus on the flexibility of these methods in order to cope with the customers' and markets' needs; surely [[Wikipedia: Agile Software Development |Agile Software Development (ASD)]] is between them.

ASD embraces the principles of [[Wikipedia:Lean Production|Lean Production]] by applying them in software development to avoid waste and increase responsiveness to change. It represents the solution to the unpredictability of the market where the capacity "to welcome change even late in development" (''K. Beck et all, 2001'')<ref name='Manifesto'></ref> is required.
This article deals with Agile Software Development with a particular focus on one of its most used technique : '''Scrum Methodology'''.

=Scrum Methodology=
Scrum is an iterative method used to develop software, it can be placed inside the group of methods which are used in '''ASD'''. This word is taken from rugby and represents that phase of the match where an ordered formation of players, with arms interlocked and heads down, push forward against a similar group to gain possession of the ball<ref name='Cohen'></ref>. This method provides that "work is divided into small chunks to manage complexity and to get early feedback from customers and end users" (''S. Augustine, 2005'')<ref>S. Augustine,2005,Prentice Hall PTR,Managing Agile Projects</ref>; software development is carried out by small working team that allow rapid adjustment during the process and a quick delivery of the final product.

==Agile Software Development==
At the end of the 20th century there were some practitioners who believed that traditional [[Wikipedia:Iterative model |Iterative model]] was not so responsive to market changes. They defined Agile a process which was able to accept change rather than stress predictability.They also believed that to well face customers’ needs development software methods have to respond to change as quickly as it arose rather than prevent changes.<ref name='Cohen'>D.Cohen,M.Lindval,P. Costa,Fraunhofer Center Maryland, Agile Software Development</ref>

It was in these circumstances that practitioners as Mary Poppendieck and Bob Charet started to take inspiration from Lean manufacturing principles and apply them to software development.
These are the main points ,according to Poppendieck, which make Lean Production so successful and that can be applied to software development:

*elimination of waste that does not add value to the customer such as diagram and models that do not add value to the final deliverable;
*minimize inventory such as requirements and design documents;
*maximize flow by using iterative development to reduce development time;
*pull from demand;
*empower workers that means “tell developer what needs to be done not how to do it";
*meet customer requirements – work closely with the customer, allowing them to change their minds
*do it right the first time – test early and refactor when necessary;
*abolish local optimization – flexibly manage scope;
*partner with suppliers – avoid adversarial relationships, work towards developing the best software;
*create a culture of continuous improvement – allow the process to improve, learn from mistakes and successes.<ref name='Cohen'></ref><ref>M. Poppendieck, T. Poppendieck, 2003, Addison Wesley, Lean Software Development: An Agile Toolkit[[http://www.poppendieck.com/]]</ref>

===Manifesto for the Agile Software development===
A few years before Poppoendieck’s publication, on February 2001,a group of seventeen software developers published in a work called “Manifesto for the Agile Software Development”<ref name='Manifesto'>K. Beck et all., 2001, Manifesto for Agile Software Development[http://www.agilemanifesto.org/]</ref> the main principles of Agile Software development.

From reading these few words it is possible to identify what are the main innovations that ASD introduced in Software development:
[[File:Agilemanifesto.jpg|400px|thumb|right|Manifesto for the Agile Software development<ref name='Manifesto'></ref>]]

*'''“Individuals and interactions”''': with these words founders want to remark the power of human being creativity and also the ability of each man to collaborate with his other similars. The stiffness of Waterfall model is instead represented by “processes and tools” where people was used to follow only what the plan required.
*'''“Working software“''': here there is a clear reference to the new way of developing software where at every iteration a working program is realised. This is different from the previous model in which a working program couldn’t be seen until the end of the project. This feature is put over the “comprehensive documentation” which characterizes especially Waterfall model.
*'''“Customer collaboration”''': it means that there must be a straight relationship between customer and developer in order to define time by time the projects requirements and evaluate every realise.
*'''“Responding to change over following a plan”''' : this sentence encloses the essence of Agile software Development that is to cope with turbulent markets by being flexible and by responding quickly to change. This concept was remarked by the founders in one of the twelve principles which follow the manifesto which says “Welcome changing requirements, even late in development […]”.<ref name='Manifesto'></ref>

=Application=
[[File:Scrum_Framework.png|350px|thumb|right|Scrum Framework]]
There are two concepts that are at the basement of Scrum methodology: '''iterative development''' and '''team working'''. Developing in iterations allow Scrum team to adapt quickly to changing requirements, while working in close location and focusing on communication allow team to make decisions and act on them immediately rather than wait on correspondence.<ref name='Cohen'></ref>

Basically Scrum consists in a sequence of fixed-length iterations called '''Sprint''' that are the fundamental units in which the whole project is divided. As the picture shows Scrum framework is really simple: it starts from a vision like all projects. This idea is converted into a plan during the preliminary meetings where customers and developers identifies the main software requirements and defines the Product Backlog. This represents the entire amount of work that has to be done in order to develop the software. In the next step Product Backlog is divided into several Sprint Backlogs that define which tasks have to be done during the following Sprint. During these iterations the product experiences an incremental development at the end of which it is potentially shippable.

Every Sprint is managed by one or more '''cross-functional and self-organizing teams''' each composed by seven people. There are also other two actors whose task is to be supportive of the software development. One is the '''Product Owner''' who mainly handles customers contacts, and the other is the '''Scrum Master''' whose main task is to ensure that development team can work without obstacles.

Each sprint usually lasts from 2 to 4 weeks, in this period there are at least one meeting between the Product Owner and Development Team in order to define the main objectives; then there are also short daily meetings held every morning to enhance communication, inform customers, developers, and managers on the status of the project, identify any problems encountered, and keep the entire team focused on a common goal.<ref name='Cohen'></ref>

==Main Actors in Scrum==
===Product Owner===
Product owner is the link between customers and development team, he ensures that deliverables are in line with customers’ expectation and that stakeholders’ interests are fulfilled. He has also the task to fill out customer-centric items (typically '''user stories'''), ranks and prioritizes them before adds them to the '''Product Backlog'''.

Usually development teams have only one Product owner, but differently from the Scrum master, he only takes care of the business side and does not interfere with the scrum team about the technological issues. At the beginning of each Sprint the Product Owner holds a Sprint Planning Meeting to state on which Product Backlog Items Scrum team will go to work during the next Sprint. In this phase he defines what are the most important items for that business, in according to the customer’s needs.

===Development Team===
Development team task is to deliver Product Backlog Items (PBIs) at the end of every Sprint in according with customers’ requirements.
Usually each team is composed by '''cross-functional members''' that allow an all-round software development; the main figures that there must be are a mix of software engineers, architects, programmers, analysts, QA experts, testers, and UI designers.

The size of the team is an important point, the group members' number influences capacity of people to communicate and work together: it is recommended that a scrum team is composed not more than nine people, usually seven.

Another peculiarity of Scrum team is its Self-organization which facilitates members’ creativity and increases team cohesiveness. For this reason it is recommended to not change the members of a team after they have worked together, especially if they had success in their project. After working together team members gain a mutual understanding that increases their capacity of team working, this synergy cannot be acquired if team are continuously changed.

A further point that characterized the good outcomes of a scrum team is location: people are most successful when located in the same room, particularly for the first few Sprints, this facilitates communication and information sharing.

====Team self-organization====
Team self-organization is a crucial point in the scrum methodology. This new concept is well explained by the sentence “it is told developer what needs to be done not how to do it”<ref name='Cohen'></ref>. It means that they can autonomously choose the way to reach commitments.
Furthermore, as it is explained previously, during Sprint execution, team members develop an intrinsic interest in shared goals in this way self-organizing teams can radically outperform larger than traditionally managed teams. It has to be specified that an optimal self-organization takes time: it may be possible that for the first few sprints developers perform worse than when they work in the traditional way.

Some requirements are necessary to gain a good team self-organization:
*members are committed to clear, short-term goals;
*members can gauge the group’s progress;
*members can observe each other’s contribution;
*members feel safe to give each other unvarnished feedback.<ref name='James'>M. James,2010,Scrum Reference Card, Michael James,[[http://scrumreferencecard.com/]]</ref>

Conversely there are some conditions that can hamper self-organization:
*geographical distribution: it is better if the whole team work in a room;
*boss/work dynamics: each member has to consider the others as peer to facilitate a fair communication between them;
*part-time team members;
*interruptions unrelated to Sprint goals.

===Scrum Master===
The scrum master worries that Scrum team can work without obstacles but he has no management authority over them. Essentially he has the aim to:
*create an environment to promote team self-organization;
*support team in the achievement of expected goals;
*ensure that events (e.g. daily Scrum meeting) take place in the right way;
*keep '''Scrum artefacts''' visible ('''Product Backlog''', '''Sprint Backlog''', '''Sprint burndown chart''' …).

==Sprint==
As it is already explained before Sprint (or iteration) is the fundamental unit in which the whole project is divided. It is characterized by a fixed length of 2 weeks or 30 days and by a goal to achieve. At the beginning of each sprint Scrum team , Product Owner , Scrum Master and sometimes also stakeholders hold a meeting, called Sprint Planning meeting. During this encounter it is defined the Sprint Backlog which states what are the goals and requirements of the next Sprint. After this further meetings inside development team will be held in order to define in more detail how achieving the common goals stated in the previous meetings.
==Scrum Meetings==
[[File:Scrum_meetings.png|350px|thumb|right|Scrum Meetings<ref name='James'></ref>]]
Meetings are the fundamental tool used during the whole Scrum process. Usually they are facilitated by the Scrum master who however has no decision-making authority over them. There are different typologies of meetings according to the different phase of the process in which we are.
===Sprint Planning Meeting===
At the beginning of each Sprint, the Product Owner and team hold a Sprint Planning Meeting to define on which '''Product Backlog Items (PBIs)''' they will go to work during the next Sprint. During this meeting "The Product Owner is responsible for declaring which items are the most important to the business" instead "the team is responsible for selecting the amount of work they feel they can implement" (''M. James, 2010'')<ref name='James'></ref>.In this phase in perfect Lean perspective the team “pulls” work from the Product Backlog to the Sprint Backlog. At the end of the meeting the selected items are broken into a provisional list of Sprint task. The maximum time that can be used to do Planning meeting, known as '''timebox''', is of eight hours.

===Daily Scrum and Sprint Execution===
During the sprint every day members of the Scrum team hold a fifteen minutes meeting where they take stock of the situation. Usually they speak about what they did the previous day, which impediments they faced and what they are going to do in the current day. To make these meetings shorter it is better that people are standing.
During sprint execution it is common to find out additional tasks necessary to achieve sprint goal; to keep the control over processes during sprint development it could be useful to maintain a current '''Sprint Task List''', a '''Sprint Burndown Chart''', and an '''Impediments List''': these are some artefacts that allow developer to understand where the project is located.

===Sprint Review Meeting===
At the end of every Sprint it is held a Review meeting where the scrum team has to explain to the Product Owner what they did during the previous sprint. Usually this meeting consists in a live demonstration of the working product increment after which Product Owner states which Items can be considered as done.
Items which are declared not done have to return to the Product Backlog to be ranked and reprioritized by the Product Owner with the help of the Scrum master. Last step of this meeting is to convert stakeholders’ feedback to a new Product Log, this task is consigned to both Product Owner and Scrum Master.
The Sprint Review Meeting is the appropriate meeting for external stakeholders (even end users) to attend.

===Sprint Retrospective Meeting===
During this meeting every member of the scrum team inspects his behaviour to identify some impediments that he faced during the Sprint. There are mainly three kind of impediments in which developers can be involved:
*people who conduct performance evaluation are an obstacles to transparency of the team;
*human tendency of someone in the team to jump to conclusions and propose actions too quickly;
*geographical distribution of the team can be an impediments, team work better if they are delimited in a small place like a room.<ref name='James'></ref>

After identifying all these impediments Scrum master has the task to eliminate them.

===Backlog Refinement Meeting ===
Especially at the beginning of the project "most of the Product Backlog Items (PBIs) need refinement because they are too large and poorly understood" (''M. James, 2010'')<ref name='James'></ref>. In the Backlog Refinement Meeting, the gives an estimation of the remaining work that is required to complete the Items in the Product Backlog and provides other technical informations in order to help the Product Owner to prioritize them.

==Artefacts==
[[File:Product_Backlog_2.png|350px|thumb|right|Product Backlog and Sprint Backlog<ref name='James'></ref>]]
===Product Backlog===

It is defined before the project beginning and then upgraded during the Backlog Refinement meeting ; it is made up by the whole group of items which have to be completed during the project in order to realize the final product. Every item is ranked and constantly reprioritized by the Product Owner. It is important that Product Backlog is visible to the stakeholders.

===Product Backlog Item (PBI)===
An item specifies what has to be done but not how do it. Usually they are written in a User story to be understood also by stakeholders. Every items has a work load of 2-3 days and requires 2-3 people. It represents the basic unit of the Product backlog.
[[File:Sprint_Backlog.png|200px|thumb|right|Sprint Backlog<ref name='James'></ref>]]
===Sprint backlog===

It is defined at the beginning of each sprint during the Sprint Planning meeting where the committed items and the main task that have to be done during the sprint are identified. It has to be visible to the Scrum team and also upgraded during the sprint execution with the additional tasks necessary to achieve the final goal.

===Sprint task===
Every item is divided into several tasks, each of them requires one day or less of work. A sprint task specifies how to achieve what is required by PBI. If the task takes more than one day of work, remaining effort is re-estimated daily, typically in hours.

===Sprint Burndown Chart===
[[File:Sprint_burndown_chart.png|300px|thumb|right|Sprint Burndown Chart<ref name='James'></ref>]]
This tool is used to facilitate self-organization of the team. It indicates the total remaining team task hours within one Sprint. Usually chart shows a decreasing line but if there are some re-estimation it may be possible that line increase for then going down. As picture shows it has a time line in the x axis and the remaining hours of work within one Sprint in the y axis. The advantage of this tool is to show at a first sight at which point of the project you are and the work that is left to complete the Sprint. It is important that this tool is used only as help to Scrum team; in some situations it could become a constraint for developers, in this case Scrum Master has to remove this chart from the room.

=Limitations=
Scrum method was often used in the object-oriented software development. Actually this technique are applied not only on software but also on other products from different sectors like wheelchairs, semiconductors and mortgages.
Scrum has to be used in those projects where people cannot rely on the plan-driven approaches like Waterfall, because of unknown requirements and technology.
[[File:Graph.png|300px|thumb|right|Predictability of a Project<ref name='James'></ref>]]
Conversely if the projects is placed under precise and stable conditions it is better to use one of the traditional model which allow to have a fixed planning over the whole project. In this case Scrum method would involve in a waste of resources and money because he is working on a field that is not its responsibility.

Michael James in his “Scrum Reference card” explains with a simple graphics in which conditions Scrum should be used and which ones are not. James defines the predictability of the projects on the base of two features: knowledge of the requirements and knowledge of the level of technology required. A project which provides known requirements and a known level of technology should be carried out with a plan-driven model. It these conditions are not met it is better to use an empirical approach like Scrum.<ref name='James'></ref>

=References=
<references/>

Scrum Methodology in Agile Software Development

2015-09-28T21:39:28Z

S150821: /* Application */

Today market is affected by uncertainly and sudden changes, in these conditions most of the models used in the 20th century to develop software are not still appropriate.[[Wikipedia:Waterfall model | Waterfall model]] , probably the most famous between them, is characterized by a stiff structure which can’t cope with the turbulent needs of the actual market.
In recent years many innovations are been enhanced in software engineering with a particular focus on the flexibility of these methods in order to cope with the customers' and markets' needs; surely [[Wikipedia: Agile Software Development |Agile Software Development (ASD)]] is between them.

ASD embraces the principles of [[Wikipedia:Lean Production|Lean Production]] by applying them in software development to avoid waste and increase responsiveness to change. It represents the solution to the unpredictability of the market where the capacity "to welcome change even late in development" (''K. Beck et all, 2001'')<ref name='Manifesto'></ref> is required.
This article deals with Agile Software Development with a particular focus on one of its most used technique : '''Scrum Methodology'''.

=Scrum Methodology=
Scrum is an iterative method used to develop software, it can be placed inside the group of methods which are used in '''ASD'''. This word is taken from rugby and represents that phase of the match where an ordered formation of players, with arms interlocked and heads down, push forward against a similar group to gain possession of the ball<ref name='Cohen'></ref>. This method provides that "work is divided into small chunks to manage complexity and to get early feedback from customers and end users" (''S. Augustine, 2005'')<ref>S. Augustine,2005,Prentice Hall PTR,Managing Agile Projects</ref>; software development is carried out by small working team that allow rapid adjustment during the process and a quick delivery of the final product.

==Agile Software Development==
At the end of the 20th century there were some practitioners who believed that traditional [[Wikipedia:Iterative model |Iterative model]] was not so responsive to market changes. They defined Agile a process which was able to accept change rather than stress predictability.They also believed that to well face customers’ needs development software methods have to respond to change as quickly as it arose rather than prevent changes.<ref name='Cohen'>D.Cohen,M.Lindval,P. Costa,Fraunhofer Center Maryland, Agile Software Development</ref>

It was in these circumstances that practitioners as Mary Poppendieck and Bob Charet started to take inspiration from Lean manufacturing principles and apply them to software development.
These are the main points ,according to Poppendieck, which make Lean Production so successful and that can be applied to software development:

*elimination of waste that does not add value to the customer such as diagram and models that do not add value to the final deliverable;
*minimize inventory such as requirements and design documents;
*maximize flow by using iterative development to reduce development time;
*pull from demand;
*empower workers that means “tell developer what needs to be done not how to do it";
*meet customer requirements – work closely with the customer, allowing them to change their minds
*do it right the first time – test early and refactor when necessary;
*abolish local optimization – flexibly manage scope;
*partner with suppliers – avoid adversarial relationships, work towards developing the best software;
*create a culture of continuous improvement – allow the process to improve, learn from mistakes and successes.<ref name='Cohen'></ref><ref>M. Poppendieck, T. Poppendieck, 2003, Addison Wesley, Lean Software Development: An Agile Toolkit[[http://www.poppendieck.com/]]</ref>

===Manifesto for the Agile Software development===
A few years before Poppoendieck’s publication, on February 2001,a group of seventeen software developers published in a work called “Manifesto for the Agile Software Development”<ref name='Manifesto'>K. Beck et all., 2001, Manifesto for Agile Software Development[http://www.agilemanifesto.org/]</ref> the main principles of Agile Software development.

From reading these few words it is possible to identify what are the main innovations that ASD introduced in Software development:
[[File:Agilemanifesto.jpg|400px|thumb|right|Manifesto for the Agile Software development<ref name='Manifesto'></ref>]]

*'''“Individuals and interactions”''': with these words founders want to remark the power of human being creativity and also the ability of each man to collaborate with his other similars. The stiffness of Waterfall model is instead represented by “processes and tools” where people was used to follow only what the plan required.
*'''“Working software“''': here there is a clear reference to the new way of developing software where at every iteration a working program is realised. This is different from the previous model in which a working program couldn’t be seen until the end of the project. This feature is put over the “comprehensive documentation” which characterizes especially Waterfall model.
*'''“Customer collaboration”''': it means that there must be a straight relationship between customer and developer in order to define time by time the projects requirements and evaluate every realise.
*'''“Responding to change over following a plan”''' : this sentence encloses the essence of Agile software Development that is to cope with turbulent markets by being flexible and by responding quickly to change. This concept was remarked by the founders in one of the twelve principles which follow the manifesto which says “Welcome changing requirements, even late in development […]”.<ref name='Manifesto'></ref>

=Application=
[[File:Scrum_Framework.png|350px|thumb|right|Scrum Framework]]
There are two concepts that are at the basement of Scrum methodology: '''iterative development''' and '''team working'''. Developing in iterations allow Scrum team to adapt quickly to changing requirements, while working in close location and focusing on communication allow team to make decisions and act on them immediately rather than wait on correspondence.<ref name='Cohen'></ref>

Basically Scrum consists in a sequence of fixed-length iterations called '''Sprint''' that are the fundamental units in which the whole project is divided. As the picture shows Scrum framework is really simple: it starts from a vision like all projects. This idea is converted into a plan during the preliminary meetings where customers and developers identifies the main software requirements and defines the Product Backlog. This represents the entire amount of work that has to be done in order to develop the software. In the next step Product Backlog is divided into several Sprint Backlogs that define which tasks have to be done during the following Sprint. During these iterations the product experiences an incremental development at the end of which it is potentially shippable.

Every Sprint is managed by one or more '''cross-functional and self-organizing teams''' each composed by seven people. There are also other two actors whose task is to be supportive of the software development. One is the '''Product Owner''' who mainly handles customers contacts, and the other is the '''Scrum Master''' whose main task is to ensure that development team can work without obstacles.

Each sprint usually lasts from 2 to 4 weeks, in this period there are at least one meeting between the Product Owner and Development Team in order to define the main objectives; then there are also short daily meetings held every morning to enhance communication, inform customers, developers, and managers on the status of the project, identify any problems encountered, and keep the entire team focused on a common goal.<ref name='Cohen'></ref>

==Main Actors in Scrum==
===Product Owner===
Product owner is the link between customers and development team, he ensures that deliverables are in line with customers’ expectation and that stakeholders’ interests are fulfilled. He has also the task to fill out customer-centric items (typically '''user stories'''), ranks and prioritizes them before adds them to the '''Product Backlog'''.

Usually development teams have only one Product owner, but differently from the Scrum master, he only takes care of the business side and does not interfere with the scrum team about the technological issues. At the beginning of each Sprint the Product Owner holds a Sprint Planning Meeting to state on which Product Backlog Items Scrum team will go to work during the next Sprint. In this phase he defines what are the most important items for that business, in according to the customer’s needs.

===Development Team===
Development team task is to deliver Product Backlog Items (PBIs) at the end of every Sprint in according with customers’ requirements.
Usually each team is composed by '''cross-functional members''' that allow an all-round software development; the main figures that there must be are a mix of software engineers, architects, programmers, analysts, QA experts, testers, and UI designers.

The size of the team is an important point, the group members' number influences capacity of people to communicate and work together: it is recommended that a scrum team is composed not more than nine people, usually seven.

Another peculiarity of Scrum team is its Self-organization which facilitates members’ creativity and increases team cohesiveness. For this reason it is recommended to not change the members of a team after they have worked together, especially if they had success in their project. After working together team members gain a mutual understanding that increases their capacity of team working, this synergy cannot be acquired if team are continuously changed.

A further point that characterized the good outcomes of a scrum team is location: people are most successful when located in the same room, particularly for the first few Sprints: this facilitates communication and information sharing.

====Team self-organization====
Team self-organization is a crucial point in the scrum methodology. This new concept is well explained by the sentence “it is told developer what needs to be done not how to do it”<ref name='Cohen'></ref>. It means that they can autonomously choose the way to reach commitments.
Furthermore, as it is explained previously, during Sprint execution, team members develop an intrinsic interest in shared goals in this way self-organizing teams can radically outperform larger than traditionally managed teams. It has to be specified that an optimal self-organization takes time: it may be possible that for the first few sprints developers perform worse than when they work in the traditional way.

Some requirements are necessary to gain a good team self-organization:
*members are committed to clear, short-term goals;
*members can gauge the group’s progress;
*members can observe each other’s contribution;
*members feel safe to give each other unvarnished feedback.<ref name='James'>M. James,2010,Scrum Reference Card, Michael James,[[http://scrumreferencecard.com/]]</ref>

Conversely there are some conditions that can hamper self-organization:
*geographical distribution: it is better if the whole team work in a room;
*boss/work dynamics: each member has to consider the others as peer to facilitate a fair communication between them;
*part-time team members;
*interruptions unrelated to Sprint goals.

===Scrum Master===
The scrum master worries that Scrum team can work without obstacles but he has no management authority over them. Essentially he has the aim to:
*create an environment to promote team self-organization;
*support team in the achievement of expected goals;
*ensure that events (e.g. daily Scrum meeting) take place in the right way;
*keep '''Scrum artefacts''' visible ('''Product Backlog''', '''Sprint Backlog''', '''Sprint burndown chart''' …).

==Sprint==
As it is already explained before Sprint (or iteration) is the fundamental unit in which the whole project is divided. It is characterized by a fixed length of 2 weeks or 30 days and by a goal to achieve. At the beginning of each sprint Scrum team , Product Owner , Scrum Master and sometimes also stakeholders hold a meeting, called Sprint Planning meeting. During this encounter it is defined the Sprint Backlog which states what are the goals and requirements of the next Sprint. After this further meetings inside development team will be held in order to define in more detail how achieving the common goals stated in the previous meetings.
==Scrum Meetings==
[[File:Scrum_meetings.png|350px|thumb|right|Scrum Meetings<ref name='James'></ref>]]
Meetings are the fundamental tool used during the whole Scrum process. Usually they are facilitated by the Scrum master who however has no decision-making authority over them. There are different typologies of meetings according to the different phase of the process in which we are.
===Sprint Planning Meeting===
At the beginning of each Sprint, the Product Owner and team hold a Sprint Planning Meeting to define on which '''Product Backlog Items (PBIs)''' they will go to work during the next Sprint. During this meeting "The Product Owner is responsible for declaring which items are the most important to the business" instead "the team is responsible for selecting the amount of work they feel they can implement" (''M. James, 2010'')<ref name='James'></ref>.In this phase in perfect Lean perspective the team “pulls” work from the Product Backlog to the Sprint Backlog. At the end of the meeting the selected items are broken into a provisional list of Sprint task. The maximum time that can be used to do Planning meeting, known as '''timebox''', is of eight hours.

===Daily Scrum and Sprint Execution===
During the sprint every day members of the Scrum team hold a fifteen minutes meeting where they take stock of the situation. Usually they speak about what they did the previous day, which impediments they faced and what they are going to do in the current day. To make these meetings shorter it is better that people are standing.
During sprint execution it is common to find out additional tasks necessary to achieve sprint goal; to keep the control over processes during sprint development it could be useful to maintain a current '''Sprint Task List''', a '''Sprint Burndown Chart''', and an '''Impediments List''': these are some artefacts that allow developer to understand where the project is located.

===Sprint Review Meeting===
At the end of every Sprint it is held a Review meeting where the scrum team has to explain to the Product Owner what they did during the previous sprint. Usually this meeting consists in a live demonstration of the working product increment after which Product Owner states which Items can be considered as done.
Items which are declared not done have to return to the Product Backlog to be ranked and reprioritized by the Product Owner with the help of the Scrum master. Last step of this meeting is to convert stakeholders’ feedback to a new Product Log, this task is consigned to both Product Owner and Scrum Master.
The Sprint Review Meeting is the appropriate meeting for external stakeholders (even end users) to attend.

===Sprint Retrospective Meeting===
During this meeting every member of the scrum team inspects his behaviour to identify some impediments that he faced during the Sprint. There are mainly three kind of impediments in which developers can be involved:
*people who conduct performance evaluation are an obstacles to transparency of the team;
*human tendency of someone in the team to jump to conclusions and propose actions too quickly;
*geographical distribution of the team can be an impediments, team work better if they are delimited in a small place like a room.<ref name='James'></ref>

After identifying all these impediments Scrum master has the task to eliminate them.

===Backlog Refinement Meeting ===
Especially at the beginning of the project "most of the Product Backlog Items (PBIs) need refinement because they are too large and poorly understood" (''M. James, 2010'')<ref name='James'></ref>. In the Backlog Refinement Meeting, the gives an estimation of the remaining work that is required to complete the Items in the Product Backlog and provides other technical informations in order to help the Product Owner to prioritize them.

==Artefacts==
[[File:Product_Backlog_2.png|350px|thumb|right|Product Backlog and Sprint Backlog<ref name='James'></ref>]]
===Product Backlog===

It is defined before the project beginning and then upgraded during the Backlog Refinement meeting ; it is made up by the whole group of items which have to be completed during the project in order to realize the final product. Every item is ranked and constantly reprioritized by the Product Owner. It is important that Product Backlog is visible to the stakeholders.

===Product Backlog Item (PBI)===
An item specifies what has to be done but not how do it. Usually they are written in a User story to be understood also by stakeholders. Every items has a work load of 2-3 days and requires 2-3 people. It represents the basic unit of the Product backlog.
[[File:Sprint_Backlog.png|200px|thumb|right|Sprint Backlog<ref name='James'></ref>]]
===Sprint backlog===

It is defined at the beginning of each sprint during the Sprint Planning meeting where the committed items and the main task that have to be done during the sprint are identified. It has to be visible to the Scrum team and also upgraded during the sprint execution with the additional tasks necessary to achieve the final goal.

===Sprint task===
Every item is divided into several tasks, each of them requires one day or less of work. A sprint task specifies how to achieve what is required by PBI. If the task takes more than one day of work, remaining effort is re-estimated daily, typically in hours.

===Sprint Burndown Chart===
[[File:Sprint_burndown_chart.png|300px|thumb|right|Sprint Burndown Chart<ref name='James'></ref>]]
This tool is used to facilitate self-organization of the team. It indicates the total remaining team task hours within one Sprint. Usually chart shows a decreasing line but if there are some re-estimation it may be possible that line increase for then going down. As picture shows it has a time line in the x axis and the remaining hours of work within one Sprint in the y axis. The advantage of this tool is to show at a first sight at which point of the project you are and the work that is left to complete the Sprint. It is important that this tool is used only as help to Scrum team; in some situations it could become a constraint for developers, in this case Scrum Master has to remove this chart from the room.

=Limitations=
Scrum method was often used in the object-oriented software development. Actually this technique are applied not only on software but also on other products from different sectors like wheelchairs, semiconductors and mortgages.
Scrum has to be used in those projects where people cannot rely on the plan-driven approaches like Waterfall, because of unknown requirements and technology.
[[File:Graph.png|300px|thumb|right|Predictability of a Project<ref name='James'></ref>]]
Conversely if the projects is placed under precise and stable conditions it is better to use one of the traditional model which allow to have a fixed planning over the whole project. In this case Scrum method would involve in a waste of resources and money because he is working on a field that is not its responsibility.

Michael James in his “Scrum Reference card” explains with a simple graphics in which conditions Scrum should be used and which ones are not. James defines the predictability of the projects on the base of two features: knowledge of the requirements and knowledge of the level of technology required. A project which provides known requirements and a known level of technology should be carried out with a plan-driven model. It these conditions are not met it is better to use an empirical approach like Scrum.<ref name='James'></ref>

=References=
<references/>

Scrum Methodology in Agile Software Development

2015-09-28T21:38:43Z

S150821: /* Application */

Today market is affected by uncertainly and sudden changes, in these conditions most of the models used in the 20th century to develop software are not still appropriate.[[Wikipedia:Waterfall model | Waterfall model]] , probably the most famous between them, is characterized by a stiff structure which can’t cope with the turbulent needs of the actual market.
In recent years many innovations are been enhanced in software engineering with a particular focus on the flexibility of these methods in order to cope with the customers' and markets' needs; surely [[Wikipedia: Agile Software Development |Agile Software Development (ASD)]] is between them.

ASD embraces the principles of [[Wikipedia:Lean Production|Lean Production]] by applying them in software development to avoid waste and increase responsiveness to change. It represents the solution to the unpredictability of the market where the capacity "to welcome change even late in development" (''K. Beck et all, 2001'')<ref name='Manifesto'></ref> is required.
This article deals with Agile Software Development with a particular focus on one of its most used technique : '''Scrum Methodology'''.

=Scrum Methodology=
Scrum is an iterative method used to develop software, it can be placed inside the group of methods which are used in '''ASD'''. This word is taken from rugby and represents that phase of the match where an ordered formation of players, with arms interlocked and heads down, push forward against a similar group to gain possession of the ball<ref name='Cohen'></ref>. This method provides that "work is divided into small chunks to manage complexity and to get early feedback from customers and end users" (''S. Augustine, 2005'')<ref>S. Augustine,2005,Prentice Hall PTR,Managing Agile Projects</ref>; software development is carried out by small working team that allow rapid adjustment during the process and a quick delivery of the final product.

==Agile Software Development==
At the end of the 20th century there were some practitioners who believed that traditional [[Wikipedia:Iterative model |Iterative model]] was not so responsive to market changes. They defined Agile a process which was able to accept change rather than stress predictability.They also believed that to well face customers’ needs development software methods have to respond to change as quickly as it arose rather than prevent changes.<ref name='Cohen'>D.Cohen,M.Lindval,P. Costa,Fraunhofer Center Maryland, Agile Software Development</ref>

It was in these circumstances that practitioners as Mary Poppendieck and Bob Charet started to take inspiration from Lean manufacturing principles and apply them to software development.
These are the main points ,according to Poppendieck, which make Lean Production so successful and that can be applied to software development:

*elimination of waste that does not add value to the customer such as diagram and models that do not add value to the final deliverable;
*minimize inventory such as requirements and design documents;
*maximize flow by using iterative development to reduce development time;
*pull from demand;
*empower workers that means “tell developer what needs to be done not how to do it";
*meet customer requirements – work closely with the customer, allowing them to change their minds
*do it right the first time – test early and refactor when necessary;
*abolish local optimization – flexibly manage scope;
*partner with suppliers – avoid adversarial relationships, work towards developing the best software;
*create a culture of continuous improvement – allow the process to improve, learn from mistakes and successes.<ref name='Cohen'></ref><ref>M. Poppendieck, T. Poppendieck, 2003, Addison Wesley, Lean Software Development: An Agile Toolkit[[http://www.poppendieck.com/]]</ref>

===Manifesto for the Agile Software development===
A few years before Poppoendieck’s publication, on February 2001,a group of seventeen software developers published in a work called “Manifesto for the Agile Software Development”<ref name='Manifesto'>K. Beck et all., 2001, Manifesto for Agile Software Development[http://www.agilemanifesto.org/]</ref> the main principles of Agile Software development.

From reading these few words it is possible to identify what are the main innovations that ASD introduced in Software development:
[[File:Agilemanifesto.jpg|400px|thumb|right|Manifesto for the Agile Software development<ref name='Manifesto'></ref>]]

*'''“Individuals and interactions”''': with these words founders want to remark the power of human being creativity and also the ability of each man to collaborate with his other similars. The stiffness of Waterfall model is instead represented by “processes and tools” where people was used to follow only what the plan required.
*'''“Working software“''': here there is a clear reference to the new way of developing software where at every iteration a working program is realised. This is different from the previous model in which a working program couldn’t be seen until the end of the project. This feature is put over the “comprehensive documentation” which characterizes especially Waterfall model.
*'''“Customer collaboration”''': it means that there must be a straight relationship between customer and developer in order to define time by time the projects requirements and evaluate every realise.
*'''“Responding to change over following a plan”''' : this sentence encloses the essence of Agile software Development that is to cope with turbulent markets by being flexible and by responding quickly to change. This concept was remarked by the founders in one of the twelve principles which follow the manifesto which says “Welcome changing requirements, even late in development […]”.<ref name='Manifesto'></ref>

=Application=
[[File:Scrum_Framework.png|350px|thumb|right|Scrum Framework]]
There are two concepts that are at the basement of Scrum methodology: '''iterative development''' and '''team working'''. Developing in iterations allow Scrum team to adapt quickly to changing requirements, while working in close location and focusing on communication allow team to make decisions and act on them immediately rather than wait on correspondence.<ref name='Cohen'></ref>

Basically Scrum consists in a sequence of fixed-length iterations called '''Sprint''' that are the fundamental units in which the whole project is divided. As the picture shows Scrum framework is really simple: it starts from a vision like all projects. This idea is converted into a plan during the preliminary meetings where customers and developers identifies the main software requirements and defines the Product Backlog. This represents the entire amount of work that has to be done in order to develop the software. In the next step Product Backlog is divided into several Sprint Backlogs that define which tasks have to be done during the following Sprint. During these iterations the product experiences an incremental development at the end of which it is potentially shippable.

Every Sprint is managed by one or more '''cross-functional and self-organizing teams''' each composed by seven people. There are also other two actors whose task is to be supportive of the software development. One is '''Product Owner''' who mainly handles customers contacts, and the other is '''Scrum Master''' whose main task is to ensure that development team can work without obstacles.

Each sprint usually lasts from 2 to 4 weeks, in this period there are at least one meeting between the Product Owner and Development Team in order to define the main objectives; then there are also short daily meetings held every morning to enhance communication, inform customers, developers, and managers on the status of the project, identify any problems encountered, and keep the entire team focused on a common goal.<ref name='Cohen'></ref>

==Main Actors in Scrum==
===Product Owner===
Product owner is the link between customers and development team, he ensures that deliverables are in line with customers’ expectation and that stakeholders’ interests are fulfilled. He has also the task to fill out customer-centric items (typically '''user stories'''), ranks and prioritizes them before adds them to the '''Product Backlog'''.

Usually development teams have only one Product owner, but differently from the Scrum master, he only takes care of the business side and does not interfere with the scrum team about the technological issues. At the beginning of each Sprint the Product Owner holds a Sprint Planning Meeting to state on which Product Backlog Items Scrum team will go to work during the next Sprint. In this phase he defines what are the most important items for that business, in according to the customer’s needs.

===Development Team===
Development team task is to deliver Product Backlog Items (PBIs) at the end of every Sprint in according with customers’ requirements.
Usually each team is composed by '''cross-functional members''' that allow an all-round software development; the main figures that there must be are a mix of software engineers, architects, programmers, analysts, QA experts, testers, and UI designers.

The size of the team is an important point, the group members' number influences capacity of people to communicate and work together: it is recommended that a scrum team is composed not more than nine people, usually seven.

Another peculiarity of Scrum team is its Self-organization which facilitates members’ creativity and increases team cohesiveness. For this reason it is recommended to not change the members of a team after they have worked together, especially if they had success in their project. After working together team members gain a mutual understanding that increases their capacity of team working, this synergy cannot be acquired if team are continuously changed.

A further point that characterized the good outcomes of a scrum team is location: people are most successful when located in the same room, particularly for the first few Sprints: this facilitates communication and information sharing.

====Team self-organization====
Team self-organization is a crucial point in the scrum methodology. This new concept is well explained by the sentence “it is told developer what needs to be done not how to do it”<ref name='Cohen'></ref>. It means that they can autonomously choose the way to reach commitments.
Furthermore, as it is explained previously, during Sprint execution, team members develop an intrinsic interest in shared goals in this way self-organizing teams can radically outperform larger than traditionally managed teams. It has to be specified that an optimal self-organization takes time: it may be possible that for the first few sprints developers perform worse than when they work in the traditional way.

Some requirements are necessary to gain a good team self-organization:
*members are committed to clear, short-term goals;
*members can gauge the group’s progress;
*members can observe each other’s contribution;
*members feel safe to give each other unvarnished feedback.<ref name='James'>M. James,2010,Scrum Reference Card, Michael James,[[http://scrumreferencecard.com/]]</ref>

Conversely there are some conditions that can hamper self-organization:
*geographical distribution: it is better if the whole team work in a room;
*boss/work dynamics: each member has to consider the others as peer to facilitate a fair communication between them;
*part-time team members;
*interruptions unrelated to Sprint goals.

===Scrum Master===
The scrum master worries that Scrum team can work without obstacles but he has no management authority over them. Essentially he has the aim to:
*create an environment to promote team self-organization;
*support team in the achievement of expected goals;
*ensure that events (e.g. daily Scrum meeting) take place in the right way;
*keep '''Scrum artefacts''' visible ('''Product Backlog''', '''Sprint Backlog''', '''Sprint burndown chart''' …).

==Sprint==
As it is already explained before Sprint (or iteration) is the fundamental unit in which the whole project is divided. It is characterized by a fixed length of 2 weeks or 30 days and by a goal to achieve. At the beginning of each sprint Scrum team , Product Owner , Scrum Master and sometimes also stakeholders hold a meeting, called Sprint Planning meeting. During this encounter it is defined the Sprint Backlog which states what are the goals and requirements of the next Sprint. After this further meetings inside development team will be held in order to define in more detail how achieving the common goals stated in the previous meetings.
==Scrum Meetings==
[[File:Scrum_meetings.png|350px|thumb|right|Scrum Meetings<ref name='James'></ref>]]
Meetings are the fundamental tool used during the whole Scrum process. Usually they are facilitated by the Scrum master who however has no decision-making authority over them. There are different typologies of meetings according to the different phase of the process in which we are.
===Sprint Planning Meeting===
At the beginning of each Sprint, the Product Owner and team hold a Sprint Planning Meeting to define on which '''Product Backlog Items (PBIs)''' they will go to work during the next Sprint. During this meeting "The Product Owner is responsible for declaring which items are the most important to the business" instead "the team is responsible for selecting the amount of work they feel they can implement" (''M. James, 2010'')<ref name='James'></ref>.In this phase in perfect Lean perspective the team “pulls” work from the Product Backlog to the Sprint Backlog. At the end of the meeting the selected items are broken into a provisional list of Sprint task. The maximum time that can be used to do Planning meeting, known as '''timebox''', is of eight hours.

===Daily Scrum and Sprint Execution===
During the sprint every day members of the Scrum team hold a fifteen minutes meeting where they take stock of the situation. Usually they speak about what they did the previous day, which impediments they faced and what they are going to do in the current day. To make these meetings shorter it is better that people are standing.
During sprint execution it is common to find out additional tasks necessary to achieve sprint goal; to keep the control over processes during sprint development it could be useful to maintain a current '''Sprint Task List''', a '''Sprint Burndown Chart''', and an '''Impediments List''': these are some artefacts that allow developer to understand where the project is located.

===Sprint Review Meeting===
At the end of every Sprint it is held a Review meeting where the scrum team has to explain to the Product Owner what they did during the previous sprint. Usually this meeting consists in a live demonstration of the working product increment after which Product Owner states which Items can be considered as done.
Items which are declared not done have to return to the Product Backlog to be ranked and reprioritized by the Product Owner with the help of the Scrum master. Last step of this meeting is to convert stakeholders’ feedback to a new Product Log, this task is consigned to both Product Owner and Scrum Master.
The Sprint Review Meeting is the appropriate meeting for external stakeholders (even end users) to attend.

===Sprint Retrospective Meeting===
During this meeting every member of the scrum team inspects his behaviour to identify some impediments that he faced during the Sprint. There are mainly three kind of impediments in which developers can be involved:
*people who conduct performance evaluation are an obstacles to transparency of the team;
*human tendency of someone in the team to jump to conclusions and propose actions too quickly;
*geographical distribution of the team can be an impediments, team work better if they are delimited in a small place like a room.<ref name='James'></ref>

After identifying all these impediments Scrum master has the task to eliminate them.

===Backlog Refinement Meeting ===
Especially at the beginning of the project "most of the Product Backlog Items (PBIs) need refinement because they are too large and poorly understood" (''M. James, 2010'')<ref name='James'></ref>. In the Backlog Refinement Meeting, the gives an estimation of the remaining work that is required to complete the Items in the Product Backlog and provides other technical informations in order to help the Product Owner to prioritize them.

==Artefacts==
[[File:Product_Backlog_2.png|350px|thumb|right|Product Backlog and Sprint Backlog<ref name='James'></ref>]]
===Product Backlog===

It is defined before the project beginning and then upgraded during the Backlog Refinement meeting ; it is made up by the whole group of items which have to be completed during the project in order to realize the final product. Every item is ranked and constantly reprioritized by the Product Owner. It is important that Product Backlog is visible to the stakeholders.

===Product Backlog Item (PBI)===
An item specifies what has to be done but not how do it. Usually they are written in a User story to be understood also by stakeholders. Every items has a work load of 2-3 days and requires 2-3 people. It represents the basic unit of the Product backlog.
[[File:Sprint_Backlog.png|200px|thumb|right|Sprint Backlog<ref name='James'></ref>]]
===Sprint backlog===

It is defined at the beginning of each sprint during the Sprint Planning meeting where the committed items and the main task that have to be done during the sprint are identified. It has to be visible to the Scrum team and also upgraded during the sprint execution with the additional tasks necessary to achieve the final goal.

===Sprint task===
Every item is divided into several tasks, each of them requires one day or less of work. A sprint task specifies how to achieve what is required by PBI. If the task takes more than one day of work, remaining effort is re-estimated daily, typically in hours.

===Sprint Burndown Chart===
[[File:Sprint_burndown_chart.png|300px|thumb|right|Sprint Burndown Chart<ref name='James'></ref>]]
This tool is used to facilitate self-organization of the team. It indicates the total remaining team task hours within one Sprint. Usually chart shows a decreasing line but if there are some re-estimation it may be possible that line increase for then going down. As picture shows it has a time line in the x axis and the remaining hours of work within one Sprint in the y axis. The advantage of this tool is to show at a first sight at which point of the project you are and the work that is left to complete the Sprint. It is important that this tool is used only as help to Scrum team; in some situations it could become a constraint for developers, in this case Scrum Master has to remove this chart from the room.

=Limitations=
Scrum method was often used in the object-oriented software development. Actually this technique are applied not only on software but also on other products from different sectors like wheelchairs, semiconductors and mortgages.
Scrum has to be used in those projects where people cannot rely on the plan-driven approaches like Waterfall, because of unknown requirements and technology.
[[File:Graph.png|300px|thumb|right|Predictability of a Project<ref name='James'></ref>]]
Conversely if the projects is placed under precise and stable conditions it is better to use one of the traditional model which allow to have a fixed planning over the whole project. In this case Scrum method would involve in a waste of resources and money because he is working on a field that is not its responsibility.

Michael James in his “Scrum Reference card” explains with a simple graphics in which conditions Scrum should be used and which ones are not. James defines the predictability of the projects on the base of two features: knowledge of the requirements and knowledge of the level of technology required. A project which provides known requirements and a known level of technology should be carried out with a plan-driven model. It these conditions are not met it is better to use an empirical approach like Scrum.<ref name='James'></ref>

=References=
<references/>

Scrum Methodology in Agile Software Development

2015-09-28T21:33:43Z

S150821: /* Manifesto for the Agile Software development */

Today market is affected by uncertainly and sudden changes, in these conditions most of the models used in the 20th century to develop software are not still appropriate.[[Wikipedia:Waterfall model | Waterfall model]] , probably the most famous between them, is characterized by a stiff structure which can’t cope with the turbulent needs of the actual market.
In recent years many innovations are been enhanced in software engineering with a particular focus on the flexibility of these methods in order to cope with the customers' and markets' needs; surely [[Wikipedia: Agile Software Development |Agile Software Development (ASD)]] is between them.

ASD embraces the principles of [[Wikipedia:Lean Production|Lean Production]] by applying them in software development to avoid waste and increase responsiveness to change. It represents the solution to the unpredictability of the market where the capacity "to welcome change even late in development" (''K. Beck et all, 2001'')<ref name='Manifesto'></ref> is required.
This article deals with Agile Software Development with a particular focus on one of its most used technique : '''Scrum Methodology'''.

=Scrum Methodology=
Scrum is an iterative method used to develop software, it can be placed inside the group of methods which are used in '''ASD'''. This word is taken from rugby and represents that phase of the match where an ordered formation of players, with arms interlocked and heads down, push forward against a similar group to gain possession of the ball<ref name='Cohen'></ref>. This method provides that "work is divided into small chunks to manage complexity and to get early feedback from customers and end users" (''S. Augustine, 2005'')<ref>S. Augustine,2005,Prentice Hall PTR,Managing Agile Projects</ref>; software development is carried out by small working team that allow rapid adjustment during the process and a quick delivery of the final product.

==Agile Software Development==
At the end of the 20th century there were some practitioners who believed that traditional [[Wikipedia:Iterative model |Iterative model]] was not so responsive to market changes. They defined Agile a process which was able to accept change rather than stress predictability.They also believed that to well face customers’ needs development software methods have to respond to change as quickly as it arose rather than prevent changes.<ref name='Cohen'>D.Cohen,M.Lindval,P. Costa,Fraunhofer Center Maryland, Agile Software Development</ref>

It was in these circumstances that practitioners as Mary Poppendieck and Bob Charet started to take inspiration from Lean manufacturing principles and apply them to software development.
These are the main points ,according to Poppendieck, which make Lean Production so successful and that can be applied to software development:

*elimination of waste that does not add value to the customer such as diagram and models that do not add value to the final deliverable;
*minimize inventory such as requirements and design documents;
*maximize flow by using iterative development to reduce development time;
*pull from demand;
*empower workers that means “tell developer what needs to be done not how to do it";
*meet customer requirements – work closely with the customer, allowing them to change their minds
*do it right the first time – test early and refactor when necessary;
*abolish local optimization – flexibly manage scope;
*partner with suppliers – avoid adversarial relationships, work towards developing the best software;
*create a culture of continuous improvement – allow the process to improve, learn from mistakes and successes.<ref name='Cohen'></ref><ref>M. Poppendieck, T. Poppendieck, 2003, Addison Wesley, Lean Software Development: An Agile Toolkit[[http://www.poppendieck.com/]]</ref>

===Manifesto for the Agile Software development===
A few years before Poppoendieck’s publication, on February 2001,a group of seventeen software developers published in a work called “Manifesto for the Agile Software Development”<ref name='Manifesto'>K. Beck et all., 2001, Manifesto for Agile Software Development[http://www.agilemanifesto.org/]</ref> the main principles of Agile Software development.

From reading these few words it is possible to identify what are the main innovations that ASD introduced in Software development:
[[File:Agilemanifesto.jpg|400px|thumb|right|Manifesto for the Agile Software development<ref name='Manifesto'></ref>]]

*'''“Individuals and interactions”''': with these words founders want to remark the power of human being creativity and also the ability of each man to collaborate with his other similars. The stiffness of Waterfall model is instead represented by “processes and tools” where people was used to follow only what the plan required.
*'''“Working software“''': here there is a clear reference to the new way of developing software where at every iteration a working program is realised. This is different from the previous model in which a working program couldn’t be seen until the end of the project. This feature is put over the “comprehensive documentation” which characterizes especially Waterfall model.
*'''“Customer collaboration”''': it means that there must be a straight relationship between customer and developer in order to define time by time the projects requirements and evaluate every realise.
*'''“Responding to change over following a plan”''' : this sentence encloses the essence of Agile software Development that is to cope with turbulent markets by being flexible and by responding quickly to change. This concept was remarked by the founders in one of the twelve principles which follow the manifesto which says “Welcome changing requirements, even late in development […]”.<ref name='Manifesto'></ref>

=Application=
[[File:Scrum_Framework.png|350px|thumb|right|Scrum Framework]]
There are two concepts that are at the basement of Scrum methodology: '''iterative development''' and '''team working'''. Developing in iterations allow Scrum team to adapt quickly to changing requirements, while working in close location and focusing on communication allow team to make decisions and act on them immediately rather than wait on correspondence.<ref name='Cohen'></ref>

Basically Scrum consists in a sequence of fixed-length iterations called '''Sprint''' that are the fundamental units in which the whole project is divided. As the picture shows Scrum framework is really simple: it starts from a vision like all projects. This idea is converted into a plan during the preliminary meetings where customers and developers identifies the main software requirements and defines the Product Backlog. This represents the entire amount of work that has to be done in order to develop the software. In the next step Product Backlog is divided into several Sprint Backlogs that define which tasks have to be done during the following Sprint. During these iterations the product experiences an incremental development at the end of which it is potentially shippable.

Every Sprint is managed by one or more '''cross-functional and self-organizing teams''' each composed by seven people. There are also other two actors whose task is to be supportive of the software development: one is '''Product Owner''' who mainly handles customers contacts, and the other is '''Scrum Master''' whose main task is to ensure that development team can work without obstacles.

Each sprint usually lasts from 2 to 4 weeks, in this period there are at least one meeting between the Product Owner and Development Team in order to define the main objectives; then there are also short daily meetings held every morning to enhance communication, inform customers, developers, and managers on the status of the project, identify any problems encountered, and keep the entire team focused on a common goal.<ref name='Cohen'></ref>

==Main Actors in Scrum==
===Product Owner===
Product owner is the link between customers and development team, he ensures that deliverables are in line with customers’ expectation and that stakeholders’ interests are fulfilled. He has also the task to fill out customer-centric items (typically '''user stories'''), ranks and prioritizes them before adds them to the '''Product Backlog'''.

Usually development teams have only one Product owner, but differently from the Scrum master, he only takes care of the business side and does not interfere with the scrum team about the technological issues. At the beginning of each Sprint the Product Owner holds a Sprint Planning Meeting to state on which Product Backlog Items Scrum team will go to work during the next Sprint. In this phase he defines what are the most important items for that business, in according to the customer’s needs.

===Development Team===
Development team task is to deliver Product Backlog Items (PBIs) at the end of every Sprint in according with customers’ requirements.
Usually each team is composed by '''cross-functional members''' that allow an all-round software development; the main figures that there must be are a mix of software engineers, architects, programmers, analysts, QA experts, testers, and UI designers.

The size of the team is an important point, the group members' number influences capacity of people to communicate and work together: it is recommended that a scrum team is composed not more than nine people, usually seven.

Another peculiarity of Scrum team is its Self-organization which facilitates members’ creativity and increases team cohesiveness. For this reason it is recommended to not change the members of a team after they have worked together, especially if they had success in their project. After working together team members gain a mutual understanding that increases their capacity of team working, this synergy cannot be acquired if team are continuously changed.

A further point that characterized the good outcomes of a scrum team is location: people are most successful when located in the same room, particularly for the first few Sprints: this facilitates communication and information sharing.

====Team self-organization====
Team self-organization is a crucial point in the scrum methodology. This new concept is well explained by the sentence “it is told developer what needs to be done not how to do it”<ref name='Cohen'></ref>. It means that they can autonomously choose the way to reach commitments.
Furthermore, as it is explained previously, during Sprint execution, team members develop an intrinsic interest in shared goals in this way self-organizing teams can radically outperform larger than traditionally managed teams. It has to be specified that an optimal self-organization takes time: it may be possible that for the first few sprints developers perform worse than when they work in the traditional way.

Some requirements are necessary to gain a good team self-organization:
*members are committed to clear, short-term goals;
*members can gauge the group’s progress;
*members can observe each other’s contribution;
*members feel safe to give each other unvarnished feedback.<ref name='James'>M. James,2010,Scrum Reference Card, Michael James,[[http://scrumreferencecard.com/]]</ref>

Conversely there are some conditions that can hamper self-organization:
*geographical distribution: it is better if the whole team work in a room;
*boss/work dynamics: each member has to consider the others as peer to facilitate a fair communication between them;
*part-time team members;
*interruptions unrelated to Sprint goals.

===Scrum Master===
The scrum master worries that Scrum team can work without obstacles but he has no management authority over them. Essentially he has the aim to:
*create an environment to promote team self-organization;
*support team in the achievement of expected goals;
*ensure that events (e.g. daily Scrum meeting) take place in the right way;
*keep '''Scrum artefacts''' visible ('''Product Backlog''', '''Sprint Backlog''', '''Sprint burndown chart''' …).

==Sprint==
As it is already explained before Sprint (or iteration) is the fundamental unit in which the whole project is divided. It is characterized by a fixed length of 2 weeks or 30 days and by a goal to achieve. At the beginning of each sprint Scrum team , Product Owner , Scrum Master and sometimes also stakeholders hold a meeting, called Sprint Planning meeting. During this encounter it is defined the Sprint Backlog which states what are the goals and requirements of the next Sprint. After this further meetings inside development team will be held in order to define in more detail how achieving the common goals stated in the previous meetings.
==Scrum Meetings==
[[File:Scrum_meetings.png|350px|thumb|right|Scrum Meetings<ref name='James'></ref>]]
Meetings are the fundamental tool used during the whole Scrum process. Usually they are facilitated by the Scrum master who however has no decision-making authority over them. There are different typologies of meetings according to the different phase of the process in which we are.
===Sprint Planning Meeting===
At the beginning of each Sprint, the Product Owner and team hold a Sprint Planning Meeting to define on which '''Product Backlog Items (PBIs)''' they will go to work during the next Sprint. During this meeting "The Product Owner is responsible for declaring which items are the most important to the business" instead "the team is responsible for selecting the amount of work they feel they can implement" (''M. James, 2010'')<ref name='James'></ref>.In this phase in perfect Lean perspective the team “pulls” work from the Product Backlog to the Sprint Backlog. At the end of the meeting the selected items are broken into a provisional list of Sprint task. The maximum time that can be used to do Planning meeting, known as '''timebox''', is of eight hours.

===Daily Scrum and Sprint Execution===
During the sprint every day members of the Scrum team hold a fifteen minutes meeting where they take stock of the situation. Usually they speak about what they did the previous day, which impediments they faced and what they are going to do in the current day. To make these meetings shorter it is better that people are standing.
During sprint execution it is common to find out additional tasks necessary to achieve sprint goal; to keep the control over processes during sprint development it could be useful to maintain a current '''Sprint Task List''', a '''Sprint Burndown Chart''', and an '''Impediments List''': these are some artefacts that allow developer to understand where the project is located.

===Sprint Review Meeting===
At the end of every Sprint it is held a Review meeting where the scrum team has to explain to the Product Owner what they did during the previous sprint. Usually this meeting consists in a live demonstration of the working product increment after which Product Owner states which Items can be considered as done.
Items which are declared not done have to return to the Product Backlog to be ranked and reprioritized by the Product Owner with the help of the Scrum master. Last step of this meeting is to convert stakeholders’ feedback to a new Product Log, this task is consigned to both Product Owner and Scrum Master.
The Sprint Review Meeting is the appropriate meeting for external stakeholders (even end users) to attend.

===Sprint Retrospective Meeting===
During this meeting every member of the scrum team inspects his behaviour to identify some impediments that he faced during the Sprint. There are mainly three kind of impediments in which developers can be involved:
*people who conduct performance evaluation are an obstacles to transparency of the team;
*human tendency of someone in the team to jump to conclusions and propose actions too quickly;
*geographical distribution of the team can be an impediments, team work better if they are delimited in a small place like a room.<ref name='James'></ref>

After identifying all these impediments Scrum master has the task to eliminate them.

===Backlog Refinement Meeting ===
Especially at the beginning of the project "most of the Product Backlog Items (PBIs) need refinement because they are too large and poorly understood" (''M. James, 2010'')<ref name='James'></ref>. In the Backlog Refinement Meeting, the gives an estimation of the remaining work that is required to complete the Items in the Product Backlog and provides other technical informations in order to help the Product Owner to prioritize them.

==Artefacts==
[[File:Product_Backlog_2.png|350px|thumb|right|Product Backlog and Sprint Backlog<ref name='James'></ref>]]
===Product Backlog===

It is defined before the project beginning and then upgraded during the Backlog Refinement meeting ; it is made up by the whole group of items which have to be completed during the project in order to realize the final product. Every item is ranked and constantly reprioritized by the Product Owner. It is important that Product Backlog is visible to the stakeholders.

===Product Backlog Item (PBI)===
An item specifies what has to be done but not how do it. Usually they are written in a User story to be understood also by stakeholders. Every items has a work load of 2-3 days and requires 2-3 people. It represents the basic unit of the Product backlog.
[[File:Sprint_Backlog.png|200px|thumb|right|Sprint Backlog<ref name='James'></ref>]]
===Sprint backlog===

It is defined at the beginning of each sprint during the Sprint Planning meeting where the committed items and the main task that have to be done during the sprint are identified. It has to be visible to the Scrum team and also upgraded during the sprint execution with the additional tasks necessary to achieve the final goal.

===Sprint task===
Every item is divided into several tasks, each of them requires one day or less of work. A sprint task specifies how to achieve what is required by PBI. If the task takes more than one day of work, remaining effort is re-estimated daily, typically in hours.

===Sprint Burndown Chart===
[[File:Sprint_burndown_chart.png|300px|thumb|right|Sprint Burndown Chart<ref name='James'></ref>]]
This tool is used to facilitate self-organization of the team. It indicates the total remaining team task hours within one Sprint. Usually chart shows a decreasing line but if there are some re-estimation it may be possible that line increase for then going down. As picture shows it has a time line in the x axis and the remaining hours of work within one Sprint in the y axis. The advantage of this tool is to show at a first sight at which point of the project you are and the work that is left to complete the Sprint. It is important that this tool is used only as help to Scrum team; in some situations it could become a constraint for developers, in this case Scrum Master has to remove this chart from the room.

=Limitations=
Scrum method was often used in the object-oriented software development. Actually this technique are applied not only on software but also on other products from different sectors like wheelchairs, semiconductors and mortgages.
Scrum has to be used in those projects where people cannot rely on the plan-driven approaches like Waterfall, because of unknown requirements and technology.
[[File:Graph.png|300px|thumb|right|Predictability of a Project<ref name='James'></ref>]]
Conversely if the projects is placed under precise and stable conditions it is better to use one of the traditional model which allow to have a fixed planning over the whole project. In this case Scrum method would involve in a waste of resources and money because he is working on a field that is not its responsibility.

Michael James in his “Scrum Reference card” explains with a simple graphics in which conditions Scrum should be used and which ones are not. James defines the predictability of the projects on the base of two features: knowledge of the requirements and knowledge of the level of technology required. A project which provides known requirements and a known level of technology should be carried out with a plan-driven model. It these conditions are not met it is better to use an empirical approach like Scrum.<ref name='James'></ref>

=References=
<references/>

Scrum Methodology in Agile Software Development

2015-09-28T21:32:40Z

S150821: /* Manifesto for the Agile Software development */

Today market is affected by uncertainly and sudden changes, in these conditions most of the models used in the 20th century to develop software are not still appropriate.[[Wikipedia:Waterfall model | Waterfall model]] , probably the most famous between them, is characterized by a stiff structure which can’t cope with the turbulent needs of the actual market.
In recent years many innovations are been enhanced in software engineering with a particular focus on the flexibility of these methods in order to cope with the customers' and markets' needs; surely [[Wikipedia: Agile Software Development |Agile Software Development (ASD)]] is between them.

ASD embraces the principles of [[Wikipedia:Lean Production|Lean Production]] by applying them in software development to avoid waste and increase responsiveness to change. It represents the solution to the unpredictability of the market where the capacity "to welcome change even late in development" (''K. Beck et all, 2001'')<ref name='Manifesto'></ref> is required.
This article deals with Agile Software Development with a particular focus on one of its most used technique : '''Scrum Methodology'''.

=Scrum Methodology=
Scrum is an iterative method used to develop software, it can be placed inside the group of methods which are used in '''ASD'''. This word is taken from rugby and represents that phase of the match where an ordered formation of players, with arms interlocked and heads down, push forward against a similar group to gain possession of the ball<ref name='Cohen'></ref>. This method provides that "work is divided into small chunks to manage complexity and to get early feedback from customers and end users" (''S. Augustine, 2005'')<ref>S. Augustine,2005,Prentice Hall PTR,Managing Agile Projects</ref>; software development is carried out by small working team that allow rapid adjustment during the process and a quick delivery of the final product.

==Agile Software Development==
At the end of the 20th century there were some practitioners who believed that traditional [[Wikipedia:Iterative model |Iterative model]] was not so responsive to market changes. They defined Agile a process which was able to accept change rather than stress predictability.They also believed that to well face customers’ needs development software methods have to respond to change as quickly as it arose rather than prevent changes.<ref name='Cohen'>D.Cohen,M.Lindval,P. Costa,Fraunhofer Center Maryland, Agile Software Development</ref>

It was in these circumstances that practitioners as Mary Poppendieck and Bob Charet started to take inspiration from Lean manufacturing principles and apply them to software development.
These are the main points ,according to Poppendieck, which make Lean Production so successful and that can be applied to software development:

*elimination of waste that does not add value to the customer such as diagram and models that do not add value to the final deliverable;
*minimize inventory such as requirements and design documents;
*maximize flow by using iterative development to reduce development time;
*pull from demand;
*empower workers that means “tell developer what needs to be done not how to do it";
*meet customer requirements – work closely with the customer, allowing them to change their minds
*do it right the first time – test early and refactor when necessary;
*abolish local optimization – flexibly manage scope;
*partner with suppliers – avoid adversarial relationships, work towards developing the best software;
*create a culture of continuous improvement – allow the process to improve, learn from mistakes and successes.<ref name='Cohen'></ref><ref>M. Poppendieck, T. Poppendieck, 2003, Addison Wesley, Lean Software Development: An Agile Toolkit[[http://www.poppendieck.com/]]</ref>

===Manifesto for the Agile Software development===
A few years before Poppoendieck’s publication, on February 2001,a group of seventeen software developers published in a work called “Manifesto for the Agile Software Development”<ref name='Manifesto'>K. Beck et all., 2001, Manifesto for Agile Software Development[http://www.agilemanifesto.org/]</ref> the main principles of Agile Software development.

From reading these few words it is possible to identify what are the main innovations that ASD introduced in Software development:
[[File:Agilemanifesto.jpg|400px|thumb|right|Manifesto for the Agile Software development<ref name='Manifesto'></ref>]]

*'''“Individuals and interactions”''': with these words founders want to remark the power of human being creativity and also the ability of each man to collaborate with his other similars. The stiffness of Waterfall model is instead represented by “processes and tools” where people was used to follow only what the plan required.
*'''“Working software“''': here there is a clear reference to the new way of developing software where at every iteration a working program is realised. This is differently from the previous model in which a working program couldn’t be seen until the end of the project. This feature is put over the “comprehensive documentation” which characterizes especially Waterfall model.
*'''“Customer collaboration”''': it means that there must be a straight relationship between customer and developer in order to define time by time the projects requirements and evaluate every realise.
*'''“Responding to change over following a plan”''' : this sentence encloses the essence of Agile software Development that is to cope with turbulent markets by being flexible and by responding quickly to change. This concept was remarked by the founders in one of the twelve principles which follow the manifesto which says “Welcome changing requirements, even late in development […]”.<ref name='Manifesto'></ref>

=Application=
[[File:Scrum_Framework.png|350px|thumb|right|Scrum Framework]]
There are two concepts that are at the basement of Scrum methodology: '''iterative development''' and '''team working'''. Developing in iterations allow Scrum team to adapt quickly to changing requirements, while working in close location and focusing on communication allow team to make decisions and act on them immediately rather than wait on correspondence.<ref name='Cohen'></ref>

Basically Scrum consists in a sequence of fixed-length iterations called '''Sprint''' that are the fundamental units in which the whole project is divided. As the picture shows Scrum framework is really simple: it starts from a vision like all projects. This idea is converted into a plan during the preliminary meetings where customers and developers identifies the main software requirements and defines the Product Backlog. This represents the entire amount of work that has to be done in order to develop the software. In the next step Product Backlog is divided into several Sprint Backlogs that define which tasks have to be done during the following Sprint. During these iterations the product experiences an incremental development at the end of which it is potentially shippable.

Every Sprint is managed by one or more '''cross-functional and self-organizing teams''' each composed by seven people. There are also other two actors whose task is to be supportive of the software development: one is '''Product Owner''' who mainly handles customers contacts, and the other is '''Scrum Master''' whose main task is to ensure that development team can work without obstacles.

Each sprint usually lasts from 2 to 4 weeks, in this period there are at least one meeting between the Product Owner and Development Team in order to define the main objectives; then there are also short daily meetings held every morning to enhance communication, inform customers, developers, and managers on the status of the project, identify any problems encountered, and keep the entire team focused on a common goal.<ref name='Cohen'></ref>

==Main Actors in Scrum==
===Product Owner===
Product owner is the link between customers and development team, he ensures that deliverables are in line with customers’ expectation and that stakeholders’ interests are fulfilled. He has also the task to fill out customer-centric items (typically '''user stories'''), ranks and prioritizes them before adds them to the '''Product Backlog'''.

Usually development teams have only one Product owner, but differently from the Scrum master, he only takes care of the business side and does not interfere with the scrum team about the technological issues. At the beginning of each Sprint the Product Owner holds a Sprint Planning Meeting to state on which Product Backlog Items Scrum team will go to work during the next Sprint. In this phase he defines what are the most important items for that business, in according to the customer’s needs.

===Development Team===
Development team task is to deliver Product Backlog Items (PBIs) at the end of every Sprint in according with customers’ requirements.
Usually each team is composed by '''cross-functional members''' that allow an all-round software development; the main figures that there must be are a mix of software engineers, architects, programmers, analysts, QA experts, testers, and UI designers.

The size of the team is an important point, the group members' number influences capacity of people to communicate and work together: it is recommended that a scrum team is composed not more than nine people, usually seven.

Another peculiarity of Scrum team is its Self-organization which facilitates members’ creativity and increases team cohesiveness. For this reason it is recommended to not change the members of a team after they have worked together, especially if they had success in their project. After working together team members gain a mutual understanding that increases their capacity of team working, this synergy cannot be acquired if team are continuously changed.

A further point that characterized the good outcomes of a scrum team is location: people are most successful when located in the same room, particularly for the first few Sprints: this facilitates communication and information sharing.

====Team self-organization====
Team self-organization is a crucial point in the scrum methodology. This new concept is well explained by the sentence “it is told developer what needs to be done not how to do it”<ref name='Cohen'></ref>. It means that they can autonomously choose the way to reach commitments.
Furthermore, as it is explained previously, during Sprint execution, team members develop an intrinsic interest in shared goals in this way self-organizing teams can radically outperform larger than traditionally managed teams. It has to be specified that an optimal self-organization takes time: it may be possible that for the first few sprints developers perform worse than when they work in the traditional way.

Some requirements are necessary to gain a good team self-organization:
*members are committed to clear, short-term goals;
*members can gauge the group’s progress;
*members can observe each other’s contribution;
*members feel safe to give each other unvarnished feedback.<ref name='James'>M. James,2010,Scrum Reference Card, Michael James,[[http://scrumreferencecard.com/]]</ref>

Conversely there are some conditions that can hamper self-organization:
*geographical distribution: it is better if the whole team work in a room;
*boss/work dynamics: each member has to consider the others as peer to facilitate a fair communication between them;
*part-time team members;
*interruptions unrelated to Sprint goals.

===Scrum Master===
The scrum master worries that Scrum team can work without obstacles but he has no management authority over them. Essentially he has the aim to:
*create an environment to promote team self-organization;
*support team in the achievement of expected goals;
*ensure that events (e.g. daily Scrum meeting) take place in the right way;
*keep '''Scrum artefacts''' visible ('''Product Backlog''', '''Sprint Backlog''', '''Sprint burndown chart''' …).

==Sprint==
As it is already explained before Sprint (or iteration) is the fundamental unit in which the whole project is divided. It is characterized by a fixed length of 2 weeks or 30 days and by a goal to achieve. At the beginning of each sprint Scrum team , Product Owner , Scrum Master and sometimes also stakeholders hold a meeting, called Sprint Planning meeting. During this encounter it is defined the Sprint Backlog which states what are the goals and requirements of the next Sprint. After this further meetings inside development team will be held in order to define in more detail how achieving the common goals stated in the previous meetings.
==Scrum Meetings==
[[File:Scrum_meetings.png|350px|thumb|right|Scrum Meetings<ref name='James'></ref>]]
Meetings are the fundamental tool used during the whole Scrum process. Usually they are facilitated by the Scrum master who however has no decision-making authority over them. There are different typologies of meetings according to the different phase of the process in which we are.
===Sprint Planning Meeting===
At the beginning of each Sprint, the Product Owner and team hold a Sprint Planning Meeting to define on which '''Product Backlog Items (PBIs)''' they will go to work during the next Sprint. During this meeting "The Product Owner is responsible for declaring which items are the most important to the business" instead "the team is responsible for selecting the amount of work they feel they can implement" (''M. James, 2010'')<ref name='James'></ref>.In this phase in perfect Lean perspective the team “pulls” work from the Product Backlog to the Sprint Backlog. At the end of the meeting the selected items are broken into a provisional list of Sprint task. The maximum time that can be used to do Planning meeting, known as '''timebox''', is of eight hours.

===Daily Scrum and Sprint Execution===
During the sprint every day members of the Scrum team hold a fifteen minutes meeting where they take stock of the situation. Usually they speak about what they did the previous day, which impediments they faced and what they are going to do in the current day. To make these meetings shorter it is better that people are standing.
During sprint execution it is common to find out additional tasks necessary to achieve sprint goal; to keep the control over processes during sprint development it could be useful to maintain a current '''Sprint Task List''', a '''Sprint Burndown Chart''', and an '''Impediments List''': these are some artefacts that allow developer to understand where the project is located.

===Sprint Review Meeting===
At the end of every Sprint it is held a Review meeting where the scrum team has to explain to the Product Owner what they did during the previous sprint. Usually this meeting consists in a live demonstration of the working product increment after which Product Owner states which Items can be considered as done.
Items which are declared not done have to return to the Product Backlog to be ranked and reprioritized by the Product Owner with the help of the Scrum master. Last step of this meeting is to convert stakeholders’ feedback to a new Product Log, this task is consigned to both Product Owner and Scrum Master.
The Sprint Review Meeting is the appropriate meeting for external stakeholders (even end users) to attend.

===Sprint Retrospective Meeting===
During this meeting every member of the scrum team inspects his behaviour to identify some impediments that he faced during the Sprint. There are mainly three kind of impediments in which developers can be involved:
*people who conduct performance evaluation are an obstacles to transparency of the team;
*human tendency of someone in the team to jump to conclusions and propose actions too quickly;
*geographical distribution of the team can be an impediments, team work better if they are delimited in a small place like a room.<ref name='James'></ref>

After identifying all these impediments Scrum master has the task to eliminate them.

===Backlog Refinement Meeting ===
Especially at the beginning of the project "most of the Product Backlog Items (PBIs) need refinement because they are too large and poorly understood" (''M. James, 2010'')<ref name='James'></ref>. In the Backlog Refinement Meeting, the gives an estimation of the remaining work that is required to complete the Items in the Product Backlog and provides other technical informations in order to help the Product Owner to prioritize them.

==Artefacts==
[[File:Product_Backlog_2.png|350px|thumb|right|Product Backlog and Sprint Backlog<ref name='James'></ref>]]
===Product Backlog===

It is defined before the project beginning and then upgraded during the Backlog Refinement meeting ; it is made up by the whole group of items which have to be completed during the project in order to realize the final product. Every item is ranked and constantly reprioritized by the Product Owner. It is important that Product Backlog is visible to the stakeholders.

===Product Backlog Item (PBI)===
An item specifies what has to be done but not how do it. Usually they are written in a User story to be understood also by stakeholders. Every items has a work load of 2-3 days and requires 2-3 people. It represents the basic unit of the Product backlog.
[[File:Sprint_Backlog.png|200px|thumb|right|Sprint Backlog<ref name='James'></ref>]]
===Sprint backlog===

It is defined at the beginning of each sprint during the Sprint Planning meeting where the committed items and the main task that have to be done during the sprint are identified. It has to be visible to the Scrum team and also upgraded during the sprint execution with the additional tasks necessary to achieve the final goal.

===Sprint task===
Every item is divided into several tasks, each of them requires one day or less of work. A sprint task specifies how to achieve what is required by PBI. If the task takes more than one day of work, remaining effort is re-estimated daily, typically in hours.

===Sprint Burndown Chart===
[[File:Sprint_burndown_chart.png|300px|thumb|right|Sprint Burndown Chart<ref name='James'></ref>]]
This tool is used to facilitate self-organization of the team. It indicates the total remaining team task hours within one Sprint. Usually chart shows a decreasing line but if there are some re-estimation it may be possible that line increase for then going down. As picture shows it has a time line in the x axis and the remaining hours of work within one Sprint in the y axis. The advantage of this tool is to show at a first sight at which point of the project you are and the work that is left to complete the Sprint. It is important that this tool is used only as help to Scrum team; in some situations it could become a constraint for developers, in this case Scrum Master has to remove this chart from the room.

=Limitations=
Scrum method was often used in the object-oriented software development. Actually this technique are applied not only on software but also on other products from different sectors like wheelchairs, semiconductors and mortgages.
Scrum has to be used in those projects where people cannot rely on the plan-driven approaches like Waterfall, because of unknown requirements and technology.
[[File:Graph.png|300px|thumb|right|Predictability of a Project<ref name='James'></ref>]]
Conversely if the projects is placed under precise and stable conditions it is better to use one of the traditional model which allow to have a fixed planning over the whole project. In this case Scrum method would involve in a waste of resources and money because he is working on a field that is not its responsibility.

Michael James in his “Scrum Reference card” explains with a simple graphics in which conditions Scrum should be used and which ones are not. James defines the predictability of the projects on the base of two features: knowledge of the requirements and knowledge of the level of technology required. A project which provides known requirements and a known level of technology should be carried out with a plan-driven model. It these conditions are not met it is better to use an empirical approach like Scrum.<ref name='James'></ref>

=References=
<references/>

Scrum Methodology in Agile Software Development

2015-09-28T21:31:50Z

S150821: /* Manifesto for the Agile Software development */

Today market is affected by uncertainly and sudden changes, in these conditions most of the models used in the 20th century to develop software are not still appropriate.[[Wikipedia:Waterfall model | Waterfall model]] , probably the most famous between them, is characterized by a stiff structure which can’t cope with the turbulent needs of the actual market.
In recent years many innovations are been enhanced in software engineering with a particular focus on the flexibility of these methods in order to cope with the customers' and markets' needs; surely [[Wikipedia: Agile Software Development |Agile Software Development (ASD)]] is between them.

ASD embraces the principles of [[Wikipedia:Lean Production|Lean Production]] by applying them in software development to avoid waste and increase responsiveness to change. It represents the solution to the unpredictability of the market where the capacity "to welcome change even late in development" (''K. Beck et all, 2001'')<ref name='Manifesto'></ref> is required.
This article deals with Agile Software Development with a particular focus on one of its most used technique : '''Scrum Methodology'''.

=Scrum Methodology=
Scrum is an iterative method used to develop software, it can be placed inside the group of methods which are used in '''ASD'''. This word is taken from rugby and represents that phase of the match where an ordered formation of players, with arms interlocked and heads down, push forward against a similar group to gain possession of the ball<ref name='Cohen'></ref>. This method provides that "work is divided into small chunks to manage complexity and to get early feedback from customers and end users" (''S. Augustine, 2005'')<ref>S. Augustine,2005,Prentice Hall PTR,Managing Agile Projects</ref>; software development is carried out by small working team that allow rapid adjustment during the process and a quick delivery of the final product.

==Agile Software Development==
At the end of the 20th century there were some practitioners who believed that traditional [[Wikipedia:Iterative model |Iterative model]] was not so responsive to market changes. They defined Agile a process which was able to accept change rather than stress predictability.They also believed that to well face customers’ needs development software methods have to respond to change as quickly as it arose rather than prevent changes.<ref name='Cohen'>D.Cohen,M.Lindval,P. Costa,Fraunhofer Center Maryland, Agile Software Development</ref>

It was in these circumstances that practitioners as Mary Poppendieck and Bob Charet started to take inspiration from Lean manufacturing principles and apply them to software development.
These are the main points ,according to Poppendieck, which make Lean Production so successful and that can be applied to software development:

*elimination of waste that does not add value to the customer such as diagram and models that do not add value to the final deliverable;
*minimize inventory such as requirements and design documents;
*maximize flow by using iterative development to reduce development time;
*pull from demand;
*empower workers that means “tell developer what needs to be done not how to do it";
*meet customer requirements – work closely with the customer, allowing them to change their minds
*do it right the first time – test early and refactor when necessary;
*abolish local optimization – flexibly manage scope;
*partner with suppliers – avoid adversarial relationships, work towards developing the best software;
*create a culture of continuous improvement – allow the process to improve, learn from mistakes and successes.<ref name='Cohen'></ref><ref>M. Poppendieck, T. Poppendieck, 2003, Addison Wesley, Lean Software Development: An Agile Toolkit[[http://www.poppendieck.com/]]</ref>

===Manifesto for the Agile Software development===
A few years before Poppoendieck’s publication, on February 2001,a group of seventeen software developers published in a work called “Manifesto for the Agile Software Development”<ref name='Manifesto'>K. Beck et all., 2001, Manifesto for Agile Software Development[http://www.agilemanifesto.org/]</ref> the main principles of Agile Software development.

From reading these few words it is possible to identify what are the main innovations that ASD introduced in Software development:
[[File:Agilemanifesto.jpg|400px|thumb|right|Manifesto for the Agile Software development<ref name='Manifesto'></ref>]]

*'''“Individuals and interactions”''': with these words founders want to remark the power of human being creativity and also the ability of each man to collaborate with his other similars. The stiffness of Waterfall model is instead represented by “processes and tools” where people was used to follow only what the plan required.
*'''“Working software“''': here is a clear reference to the new way of developing software where at every iteration a working program is realised. This is differently from the previous model in which a working program couldn’t be seen until the end of the project. This feature is put over the “comprehensive documentation” which characterizes especially Waterfall model.
*'''“Customer collaboration”''': it means that there must be a straight relationship between customer and developer in order to define time by time the projects requirements and evaluate every realise.
*'''“Responding to change over following a plan”''' : this sentence encloses the essence of Agile software Development that is to cope with turbulent markets by being flexible and by responding quickly to change. This concept was remarked by the founders in one of the twelve principles which follow the manifesto which says “Welcome changing requirements, even late in development […]”.<ref name='Manifesto'></ref>

=Application=
[[File:Scrum_Framework.png|350px|thumb|right|Scrum Framework]]
There are two concepts that are at the basement of Scrum methodology: '''iterative development''' and '''team working'''. Developing in iterations allow Scrum team to adapt quickly to changing requirements, while working in close location and focusing on communication allow team to make decisions and act on them immediately rather than wait on correspondence.<ref name='Cohen'></ref>

Basically Scrum consists in a sequence of fixed-length iterations called '''Sprint''' that are the fundamental units in which the whole project is divided. As the picture shows Scrum framework is really simple: it starts from a vision like all projects. This idea is converted into a plan during the preliminary meetings where customers and developers identifies the main software requirements and defines the Product Backlog. This represents the entire amount of work that has to be done in order to develop the software. In the next step Product Backlog is divided into several Sprint Backlogs that define which tasks have to be done during the following Sprint. During these iterations the product experiences an incremental development at the end of which it is potentially shippable.

Every Sprint is managed by one or more '''cross-functional and self-organizing teams''' each composed by seven people. There are also other two actors whose task is to be supportive of the software development: one is '''Product Owner''' who mainly handles customers contacts, and the other is '''Scrum Master''' whose main task is to ensure that development team can work without obstacles.

Each sprint usually lasts from 2 to 4 weeks, in this period there are at least one meeting between the Product Owner and Development Team in order to define the main objectives; then there are also short daily meetings held every morning to enhance communication, inform customers, developers, and managers on the status of the project, identify any problems encountered, and keep the entire team focused on a common goal.<ref name='Cohen'></ref>

==Main Actors in Scrum==
===Product Owner===
Product owner is the link between customers and development team, he ensures that deliverables are in line with customers’ expectation and that stakeholders’ interests are fulfilled. He has also the task to fill out customer-centric items (typically '''user stories'''), ranks and prioritizes them before adds them to the '''Product Backlog'''.

Usually development teams have only one Product owner, but differently from the Scrum master, he only takes care of the business side and does not interfere with the scrum team about the technological issues. At the beginning of each Sprint the Product Owner holds a Sprint Planning Meeting to state on which Product Backlog Items Scrum team will go to work during the next Sprint. In this phase he defines what are the most important items for that business, in according to the customer’s needs.

===Development Team===
Development team task is to deliver Product Backlog Items (PBIs) at the end of every Sprint in according with customers’ requirements.
Usually each team is composed by '''cross-functional members''' that allow an all-round software development; the main figures that there must be are a mix of software engineers, architects, programmers, analysts, QA experts, testers, and UI designers.

The size of the team is an important point, the group members' number influences capacity of people to communicate and work together: it is recommended that a scrum team is composed not more than nine people, usually seven.

Another peculiarity of Scrum team is its Self-organization which facilitates members’ creativity and increases team cohesiveness. For this reason it is recommended to not change the members of a team after they have worked together, especially if they had success in their project. After working together team members gain a mutual understanding that increases their capacity of team working, this synergy cannot be acquired if team are continuously changed.

A further point that characterized the good outcomes of a scrum team is location: people are most successful when located in the same room, particularly for the first few Sprints: this facilitates communication and information sharing.

====Team self-organization====
Team self-organization is a crucial point in the scrum methodology. This new concept is well explained by the sentence “it is told developer what needs to be done not how to do it”<ref name='Cohen'></ref>. It means that they can autonomously choose the way to reach commitments.
Furthermore, as it is explained previously, during Sprint execution, team members develop an intrinsic interest in shared goals in this way self-organizing teams can radically outperform larger than traditionally managed teams. It has to be specified that an optimal self-organization takes time: it may be possible that for the first few sprints developers perform worse than when they work in the traditional way.

Some requirements are necessary to gain a good team self-organization:
*members are committed to clear, short-term goals;
*members can gauge the group’s progress;
*members can observe each other’s contribution;
*members feel safe to give each other unvarnished feedback.<ref name='James'>M. James,2010,Scrum Reference Card, Michael James,[[http://scrumreferencecard.com/]]</ref>

Conversely there are some conditions that can hamper self-organization:
*geographical distribution: it is better if the whole team work in a room;
*boss/work dynamics: each member has to consider the others as peer to facilitate a fair communication between them;
*part-time team members;
*interruptions unrelated to Sprint goals.

===Scrum Master===
The scrum master worries that Scrum team can work without obstacles but he has no management authority over them. Essentially he has the aim to:
*create an environment to promote team self-organization;
*support team in the achievement of expected goals;
*ensure that events (e.g. daily Scrum meeting) take place in the right way;
*keep '''Scrum artefacts''' visible ('''Product Backlog''', '''Sprint Backlog''', '''Sprint burndown chart''' …).

==Sprint==
As it is already explained before Sprint (or iteration) is the fundamental unit in which the whole project is divided. It is characterized by a fixed length of 2 weeks or 30 days and by a goal to achieve. At the beginning of each sprint Scrum team , Product Owner , Scrum Master and sometimes also stakeholders hold a meeting, called Sprint Planning meeting. During this encounter it is defined the Sprint Backlog which states what are the goals and requirements of the next Sprint. After this further meetings inside development team will be held in order to define in more detail how achieving the common goals stated in the previous meetings.
==Scrum Meetings==
[[File:Scrum_meetings.png|350px|thumb|right|Scrum Meetings<ref name='James'></ref>]]
Meetings are the fundamental tool used during the whole Scrum process. Usually they are facilitated by the Scrum master who however has no decision-making authority over them. There are different typologies of meetings according to the different phase of the process in which we are.
===Sprint Planning Meeting===
At the beginning of each Sprint, the Product Owner and team hold a Sprint Planning Meeting to define on which '''Product Backlog Items (PBIs)''' they will go to work during the next Sprint. During this meeting "The Product Owner is responsible for declaring which items are the most important to the business" instead "the team is responsible for selecting the amount of work they feel they can implement" (''M. James, 2010'')<ref name='James'></ref>.In this phase in perfect Lean perspective the team “pulls” work from the Product Backlog to the Sprint Backlog. At the end of the meeting the selected items are broken into a provisional list of Sprint task. The maximum time that can be used to do Planning meeting, known as '''timebox''', is of eight hours.

===Daily Scrum and Sprint Execution===
During the sprint every day members of the Scrum team hold a fifteen minutes meeting where they take stock of the situation. Usually they speak about what they did the previous day, which impediments they faced and what they are going to do in the current day. To make these meetings shorter it is better that people are standing.
During sprint execution it is common to find out additional tasks necessary to achieve sprint goal; to keep the control over processes during sprint development it could be useful to maintain a current '''Sprint Task List''', a '''Sprint Burndown Chart''', and an '''Impediments List''': these are some artefacts that allow developer to understand where the project is located.

===Sprint Review Meeting===
At the end of every Sprint it is held a Review meeting where the scrum team has to explain to the Product Owner what they did during the previous sprint. Usually this meeting consists in a live demonstration of the working product increment after which Product Owner states which Items can be considered as done.
Items which are declared not done have to return to the Product Backlog to be ranked and reprioritized by the Product Owner with the help of the Scrum master. Last step of this meeting is to convert stakeholders’ feedback to a new Product Log, this task is consigned to both Product Owner and Scrum Master.
The Sprint Review Meeting is the appropriate meeting for external stakeholders (even end users) to attend.

===Sprint Retrospective Meeting===
During this meeting every member of the scrum team inspects his behaviour to identify some impediments that he faced during the Sprint. There are mainly three kind of impediments in which developers can be involved:
*people who conduct performance evaluation are an obstacles to transparency of the team;
*human tendency of someone in the team to jump to conclusions and propose actions too quickly;
*geographical distribution of the team can be an impediments, team work better if they are delimited in a small place like a room.<ref name='James'></ref>

After identifying all these impediments Scrum master has the task to eliminate them.

===Backlog Refinement Meeting ===
Especially at the beginning of the project "most of the Product Backlog Items (PBIs) need refinement because they are too large and poorly understood" (''M. James, 2010'')<ref name='James'></ref>. In the Backlog Refinement Meeting, the gives an estimation of the remaining work that is required to complete the Items in the Product Backlog and provides other technical informations in order to help the Product Owner to prioritize them.

==Artefacts==
[[File:Product_Backlog_2.png|350px|thumb|right|Product Backlog and Sprint Backlog<ref name='James'></ref>]]
===Product Backlog===

It is defined before the project beginning and then upgraded during the Backlog Refinement meeting ; it is made up by the whole group of items which have to be completed during the project in order to realize the final product. Every item is ranked and constantly reprioritized by the Product Owner. It is important that Product Backlog is visible to the stakeholders.

===Product Backlog Item (PBI)===
An item specifies what has to be done but not how do it. Usually they are written in a User story to be understood also by stakeholders. Every items has a work load of 2-3 days and requires 2-3 people. It represents the basic unit of the Product backlog.
[[File:Sprint_Backlog.png|200px|thumb|right|Sprint Backlog<ref name='James'></ref>]]
===Sprint backlog===

It is defined at the beginning of each sprint during the Sprint Planning meeting where the committed items and the main task that have to be done during the sprint are identified. It has to be visible to the Scrum team and also upgraded during the sprint execution with the additional tasks necessary to achieve the final goal.

===Sprint task===
Every item is divided into several tasks, each of them requires one day or less of work. A sprint task specifies how to achieve what is required by PBI. If the task takes more than one day of work, remaining effort is re-estimated daily, typically in hours.

===Sprint Burndown Chart===
[[File:Sprint_burndown_chart.png|300px|thumb|right|Sprint Burndown Chart<ref name='James'></ref>]]
This tool is used to facilitate self-organization of the team. It indicates the total remaining team task hours within one Sprint. Usually chart shows a decreasing line but if there are some re-estimation it may be possible that line increase for then going down. As picture shows it has a time line in the x axis and the remaining hours of work within one Sprint in the y axis. The advantage of this tool is to show at a first sight at which point of the project you are and the work that is left to complete the Sprint. It is important that this tool is used only as help to Scrum team; in some situations it could become a constraint for developers, in this case Scrum Master has to remove this chart from the room.

=Limitations=
Scrum method was often used in the object-oriented software development. Actually this technique are applied not only on software but also on other products from different sectors like wheelchairs, semiconductors and mortgages.
Scrum has to be used in those projects where people cannot rely on the plan-driven approaches like Waterfall, because of unknown requirements and technology.
[[File:Graph.png|300px|thumb|right|Predictability of a Project<ref name='James'></ref>]]
Conversely if the projects is placed under precise and stable conditions it is better to use one of the traditional model which allow to have a fixed planning over the whole project. In this case Scrum method would involve in a waste of resources and money because he is working on a field that is not its responsibility.

Michael James in his “Scrum Reference card” explains with a simple graphics in which conditions Scrum should be used and which ones are not. James defines the predictability of the projects on the base of two features: knowledge of the requirements and knowledge of the level of technology required. A project which provides known requirements and a known level of technology should be carried out with a plan-driven model. It these conditions are not met it is better to use an empirical approach like Scrum.<ref name='James'></ref>

=References=
<references/>

Scrum Methodology in Agile Software Development

2015-09-28T21:29:35Z

S150821: /* Manifesto for the Agile Software development */

Today market is affected by uncertainly and sudden changes, in these conditions most of the models used in the 20th century to develop software are not still appropriate.[[Wikipedia:Waterfall model | Waterfall model]] , probably the most famous between them, is characterized by a stiff structure which can’t cope with the turbulent needs of the actual market.
In recent years many innovations are been enhanced in software engineering with a particular focus on the flexibility of these methods in order to cope with the customers' and markets' needs; surely [[Wikipedia: Agile Software Development |Agile Software Development (ASD)]] is between them.

ASD embraces the principles of [[Wikipedia:Lean Production|Lean Production]] by applying them in software development to avoid waste and increase responsiveness to change. It represents the solution to the unpredictability of the market where the capacity "to welcome change even late in development" (''K. Beck et all, 2001'')<ref name='Manifesto'></ref> is required.
This article deals with Agile Software Development with a particular focus on one of its most used technique : '''Scrum Methodology'''.

=Scrum Methodology=
Scrum is an iterative method used to develop software, it can be placed inside the group of methods which are used in '''ASD'''. This word is taken from rugby and represents that phase of the match where an ordered formation of players, with arms interlocked and heads down, push forward against a similar group to gain possession of the ball<ref name='Cohen'></ref>. This method provides that "work is divided into small chunks to manage complexity and to get early feedback from customers and end users" (''S. Augustine, 2005'')<ref>S. Augustine,2005,Prentice Hall PTR,Managing Agile Projects</ref>; software development is carried out by small working team that allow rapid adjustment during the process and a quick delivery of the final product.

==Agile Software Development==
At the end of the 20th century there were some practitioners who believed that traditional [[Wikipedia:Iterative model |Iterative model]] was not so responsive to market changes. They defined Agile a process which was able to accept change rather than stress predictability.They also believed that to well face customers’ needs development software methods have to respond to change as quickly as it arose rather than prevent changes.<ref name='Cohen'>D.Cohen,M.Lindval,P. Costa,Fraunhofer Center Maryland, Agile Software Development</ref>

It was in these circumstances that practitioners as Mary Poppendieck and Bob Charet started to take inspiration from Lean manufacturing principles and apply them to software development.
These are the main points ,according to Poppendieck, which make Lean Production so successful and that can be applied to software development:

*elimination of waste that does not add value to the customer such as diagram and models that do not add value to the final deliverable;
*minimize inventory such as requirements and design documents;
*maximize flow by using iterative development to reduce development time;
*pull from demand;
*empower workers that means “tell developer what needs to be done not how to do it";
*meet customer requirements – work closely with the customer, allowing them to change their minds
*do it right the first time – test early and refactor when necessary;
*abolish local optimization – flexibly manage scope;
*partner with suppliers – avoid adversarial relationships, work towards developing the best software;
*create a culture of continuous improvement – allow the process to improve, learn from mistakes and successes.<ref name='Cohen'></ref><ref>M. Poppendieck, T. Poppendieck, 2003, Addison Wesley, Lean Software Development: An Agile Toolkit[[http://www.poppendieck.com/]]</ref>

===Manifesto for the Agile Software development===
A few years before Poppoendieck’s publication, on February 2001,a group of seventeen software developers published in a work called “Manifesto for the Agile Software Development”<ref name='Manifesto'>K. Beck et all., 2001, Manifesto for Agile Software Development[http://www.agilemanifesto.org/]</ref> the main principles of Agile Software development.

From reading these few words it is possible to identify what are the main innovations that ASD introduced in Software development:
[[File:Agilemanifesto.jpg|400px|thumb|right|Manifesto for the Agile Software development<ref name='Manifesto'></ref>]]

*'''“Individuals and interactions”''': with these words founders want to remark the power of human being creativity, and his ability of each man to collaborate with his other similars. The stiffness of Waterfall model is instead represented by “processes and tools” where people was used to follow only what the plan required.
*'''“Working software“''': here is a clear reference to the new way of developing software where at every iteration a working program is realised. This is differently from the previous model in which a working program couldn’t be seen until the end of the project. This feature is put over the “comprehensive documentation” which characterizes especially Waterfall model.
*'''“Customer collaboration”''': it means that there must be a straight relationship between customer and developer in order to define time by time the projects requirements and evaluate every realise.
*'''“Responding to change over following a plan”''' : this sentence encloses the essence of Agile software Development that is to cope with turbulent markets by being flexible and by responding quickly to change. This concept was remarked by the founders in one of the twelve principles which follow the manifesto which says “Welcome changing requirements, even late in development […]”.<ref name='Manifesto'></ref>

=Application=
[[File:Scrum_Framework.png|350px|thumb|right|Scrum Framework]]
There are two concepts that are at the basement of Scrum methodology: '''iterative development''' and '''team working'''. Developing in iterations allow Scrum team to adapt quickly to changing requirements, while working in close location and focusing on communication allow team to make decisions and act on them immediately rather than wait on correspondence.<ref name='Cohen'></ref>

Basically Scrum consists in a sequence of fixed-length iterations called '''Sprint''' that are the fundamental units in which the whole project is divided. As the picture shows Scrum framework is really simple: it starts from a vision like all projects. This idea is converted into a plan during the preliminary meetings where customers and developers identifies the main software requirements and defines the Product Backlog. This represents the entire amount of work that has to be done in order to develop the software. In the next step Product Backlog is divided into several Sprint Backlogs that define which tasks have to be done during the following Sprint. During these iterations the product experiences an incremental development at the end of which it is potentially shippable.

Every Sprint is managed by one or more '''cross-functional and self-organizing teams''' each composed by seven people. There are also other two actors whose task is to be supportive of the software development: one is '''Product Owner''' who mainly handles customers contacts, and the other is '''Scrum Master''' whose main task is to ensure that development team can work without obstacles.

Each sprint usually lasts from 2 to 4 weeks, in this period there are at least one meeting between the Product Owner and Development Team in order to define the main objectives; then there are also short daily meetings held every morning to enhance communication, inform customers, developers, and managers on the status of the project, identify any problems encountered, and keep the entire team focused on a common goal.<ref name='Cohen'></ref>

==Main Actors in Scrum==
===Product Owner===
Product owner is the link between customers and development team, he ensures that deliverables are in line with customers’ expectation and that stakeholders’ interests are fulfilled. He has also the task to fill out customer-centric items (typically '''user stories'''), ranks and prioritizes them before adds them to the '''Product Backlog'''.

Usually development teams have only one Product owner, but differently from the Scrum master, he only takes care of the business side and does not interfere with the scrum team about the technological issues. At the beginning of each Sprint the Product Owner holds a Sprint Planning Meeting to state on which Product Backlog Items Scrum team will go to work during the next Sprint. In this phase he defines what are the most important items for that business, in according to the customer’s needs.

===Development Team===
Development team task is to deliver Product Backlog Items (PBIs) at the end of every Sprint in according with customers’ requirements.
Usually each team is composed by '''cross-functional members''' that allow an all-round software development; the main figures that there must be are a mix of software engineers, architects, programmers, analysts, QA experts, testers, and UI designers.

The size of the team is an important point, the group members' number influences capacity of people to communicate and work together: it is recommended that a scrum team is composed not more than nine people, usually seven.

Another peculiarity of Scrum team is its Self-organization which facilitates members’ creativity and increases team cohesiveness. For this reason it is recommended to not change the members of a team after they have worked together, especially if they had success in their project. After working together team members gain a mutual understanding that increases their capacity of team working, this synergy cannot be acquired if team are continuously changed.

A further point that characterized the good outcomes of a scrum team is location: people are most successful when located in the same room, particularly for the first few Sprints: this facilitates communication and information sharing.

====Team self-organization====
Team self-organization is a crucial point in the scrum methodology. This new concept is well explained by the sentence “it is told developer what needs to be done not how to do it”<ref name='Cohen'></ref>. It means that they can autonomously choose the way to reach commitments.
Furthermore, as it is explained previously, during Sprint execution, team members develop an intrinsic interest in shared goals in this way self-organizing teams can radically outperform larger than traditionally managed teams. It has to be specified that an optimal self-organization takes time: it may be possible that for the first few sprints developers perform worse than when they work in the traditional way.

Some requirements are necessary to gain a good team self-organization:
*members are committed to clear, short-term goals;
*members can gauge the group’s progress;
*members can observe each other’s contribution;
*members feel safe to give each other unvarnished feedback.<ref name='James'>M. James,2010,Scrum Reference Card, Michael James,[[http://scrumreferencecard.com/]]</ref>

Conversely there are some conditions that can hamper self-organization:
*geographical distribution: it is better if the whole team work in a room;
*boss/work dynamics: each member has to consider the others as peer to facilitate a fair communication between them;
*part-time team members;
*interruptions unrelated to Sprint goals.

===Scrum Master===
The scrum master worries that Scrum team can work without obstacles but he has no management authority over them. Essentially he has the aim to:
*create an environment to promote team self-organization;
*support team in the achievement of expected goals;
*ensure that events (e.g. daily Scrum meeting) take place in the right way;
*keep '''Scrum artefacts''' visible ('''Product Backlog''', '''Sprint Backlog''', '''Sprint burndown chart''' …).

==Sprint==
As it is already explained before Sprint (or iteration) is the fundamental unit in which the whole project is divided. It is characterized by a fixed length of 2 weeks or 30 days and by a goal to achieve. At the beginning of each sprint Scrum team , Product Owner , Scrum Master and sometimes also stakeholders hold a meeting, called Sprint Planning meeting. During this encounter it is defined the Sprint Backlog which states what are the goals and requirements of the next Sprint. After this further meetings inside development team will be held in order to define in more detail how achieving the common goals stated in the previous meetings.
==Scrum Meetings==
[[File:Scrum_meetings.png|350px|thumb|right|Scrum Meetings<ref name='James'></ref>]]
Meetings are the fundamental tool used during the whole Scrum process. Usually they are facilitated by the Scrum master who however has no decision-making authority over them. There are different typologies of meetings according to the different phase of the process in which we are.
===Sprint Planning Meeting===
At the beginning of each Sprint, the Product Owner and team hold a Sprint Planning Meeting to define on which '''Product Backlog Items (PBIs)''' they will go to work during the next Sprint. During this meeting "The Product Owner is responsible for declaring which items are the most important to the business" instead "the team is responsible for selecting the amount of work they feel they can implement" (''M. James, 2010'')<ref name='James'></ref>.In this phase in perfect Lean perspective the team “pulls” work from the Product Backlog to the Sprint Backlog. At the end of the meeting the selected items are broken into a provisional list of Sprint task. The maximum time that can be used to do Planning meeting, known as '''timebox''', is of eight hours.

===Daily Scrum and Sprint Execution===
During the sprint every day members of the Scrum team hold a fifteen minutes meeting where they take stock of the situation. Usually they speak about what they did the previous day, which impediments they faced and what they are going to do in the current day. To make these meetings shorter it is better that people are standing.
During sprint execution it is common to find out additional tasks necessary to achieve sprint goal; to keep the control over processes during sprint development it could be useful to maintain a current '''Sprint Task List''', a '''Sprint Burndown Chart''', and an '''Impediments List''': these are some artefacts that allow developer to understand where the project is located.

===Sprint Review Meeting===
At the end of every Sprint it is held a Review meeting where the scrum team has to explain to the Product Owner what they did during the previous sprint. Usually this meeting consists in a live demonstration of the working product increment after which Product Owner states which Items can be considered as done.
Items which are declared not done have to return to the Product Backlog to be ranked and reprioritized by the Product Owner with the help of the Scrum master. Last step of this meeting is to convert stakeholders’ feedback to a new Product Log, this task is consigned to both Product Owner and Scrum Master.
The Sprint Review Meeting is the appropriate meeting for external stakeholders (even end users) to attend.

===Sprint Retrospective Meeting===
During this meeting every member of the scrum team inspects his behaviour to identify some impediments that he faced during the Sprint. There are mainly three kind of impediments in which developers can be involved:
*people who conduct performance evaluation are an obstacles to transparency of the team;
*human tendency of someone in the team to jump to conclusions and propose actions too quickly;
*geographical distribution of the team can be an impediments, team work better if they are delimited in a small place like a room.<ref name='James'></ref>

After identifying all these impediments Scrum master has the task to eliminate them.

===Backlog Refinement Meeting ===
Especially at the beginning of the project "most of the Product Backlog Items (PBIs) need refinement because they are too large and poorly understood" (''M. James, 2010'')<ref name='James'></ref>. In the Backlog Refinement Meeting, the gives an estimation of the remaining work that is required to complete the Items in the Product Backlog and provides other technical informations in order to help the Product Owner to prioritize them.

==Artefacts==
[[File:Product_Backlog_2.png|350px|thumb|right|Product Backlog and Sprint Backlog<ref name='James'></ref>]]
===Product Backlog===

It is defined before the project beginning and then upgraded during the Backlog Refinement meeting ; it is made up by the whole group of items which have to be completed during the project in order to realize the final product. Every item is ranked and constantly reprioritized by the Product Owner. It is important that Product Backlog is visible to the stakeholders.

===Product Backlog Item (PBI)===
An item specifies what has to be done but not how do it. Usually they are written in a User story to be understood also by stakeholders. Every items has a work load of 2-3 days and requires 2-3 people. It represents the basic unit of the Product backlog.
[[File:Sprint_Backlog.png|200px|thumb|right|Sprint Backlog<ref name='James'></ref>]]
===Sprint backlog===

It is defined at the beginning of each sprint during the Sprint Planning meeting where the committed items and the main task that have to be done during the sprint are identified. It has to be visible to the Scrum team and also upgraded during the sprint execution with the additional tasks necessary to achieve the final goal.

===Sprint task===
Every item is divided into several tasks, each of them requires one day or less of work. A sprint task specifies how to achieve what is required by PBI. If the task takes more than one day of work, remaining effort is re-estimated daily, typically in hours.

===Sprint Burndown Chart===
[[File:Sprint_burndown_chart.png|300px|thumb|right|Sprint Burndown Chart<ref name='James'></ref>]]
This tool is used to facilitate self-organization of the team. It indicates the total remaining team task hours within one Sprint. Usually chart shows a decreasing line but if there are some re-estimation it may be possible that line increase for then going down. As picture shows it has a time line in the x axis and the remaining hours of work within one Sprint in the y axis. The advantage of this tool is to show at a first sight at which point of the project you are and the work that is left to complete the Sprint. It is important that this tool is used only as help to Scrum team; in some situations it could become a constraint for developers, in this case Scrum Master has to remove this chart from the room.

=Limitations=
Scrum method was often used in the object-oriented software development. Actually this technique are applied not only on software but also on other products from different sectors like wheelchairs, semiconductors and mortgages.
Scrum has to be used in those projects where people cannot rely on the plan-driven approaches like Waterfall, because of unknown requirements and technology.
[[File:Graph.png|300px|thumb|right|Predictability of a Project<ref name='James'></ref>]]
Conversely if the projects is placed under precise and stable conditions it is better to use one of the traditional model which allow to have a fixed planning over the whole project. In this case Scrum method would involve in a waste of resources and money because he is working on a field that is not its responsibility.

Michael James in his “Scrum Reference card” explains with a simple graphics in which conditions Scrum should be used and which ones are not. James defines the predictability of the projects on the base of two features: knowledge of the requirements and knowledge of the level of technology required. A project which provides known requirements and a known level of technology should be carried out with a plan-driven model. It these conditions are not met it is better to use an empirical approach like Scrum.<ref name='James'></ref>

=References=
<references/>

Scrum Methodology in Agile Software Development

2015-09-28T21:28:30Z

S150821: /* Manifesto for the Agile Software development */

Today market is affected by uncertainly and sudden changes, in these conditions most of the models used in the 20th century to develop software are not still appropriate.[[Wikipedia:Waterfall model | Waterfall model]] , probably the most famous between them, is characterized by a stiff structure which can’t cope with the turbulent needs of the actual market.
In recent years many innovations are been enhanced in software engineering with a particular focus on the flexibility of these methods in order to cope with the customers' and markets' needs; surely [[Wikipedia: Agile Software Development |Agile Software Development (ASD)]] is between them.

ASD embraces the principles of [[Wikipedia:Lean Production|Lean Production]] by applying them in software development to avoid waste and increase responsiveness to change. It represents the solution to the unpredictability of the market where the capacity "to welcome change even late in development" (''K. Beck et all, 2001'')<ref name='Manifesto'></ref> is required.
This article deals with Agile Software Development with a particular focus on one of its most used technique : '''Scrum Methodology'''.

=Scrum Methodology=
Scrum is an iterative method used to develop software, it can be placed inside the group of methods which are used in '''ASD'''. This word is taken from rugby and represents that phase of the match where an ordered formation of players, with arms interlocked and heads down, push forward against a similar group to gain possession of the ball<ref name='Cohen'></ref>. This method provides that "work is divided into small chunks to manage complexity and to get early feedback from customers and end users" (''S. Augustine, 2005'')<ref>S. Augustine,2005,Prentice Hall PTR,Managing Agile Projects</ref>; software development is carried out by small working team that allow rapid adjustment during the process and a quick delivery of the final product.

==Agile Software Development==
At the end of the 20th century there were some practitioners who believed that traditional [[Wikipedia:Iterative model |Iterative model]] was not so responsive to market changes. They defined Agile a process which was able to accept change rather than stress predictability.They also believed that to well face customers’ needs development software methods have to respond to change as quickly as it arose rather than prevent changes.<ref name='Cohen'>D.Cohen,M.Lindval,P. Costa,Fraunhofer Center Maryland, Agile Software Development</ref>

It was in these circumstances that practitioners as Mary Poppendieck and Bob Charet started to take inspiration from Lean manufacturing principles and apply them to software development.
These are the main points ,according to Poppendieck, which make Lean Production so successful and that can be applied to software development:

*elimination of waste that does not add value to the customer such as diagram and models that do not add value to the final deliverable;
*minimize inventory such as requirements and design documents;
*maximize flow by using iterative development to reduce development time;
*pull from demand;
*empower workers that means “tell developer what needs to be done not how to do it";
*meet customer requirements – work closely with the customer, allowing them to change their minds
*do it right the first time – test early and refactor when necessary;
*abolish local optimization – flexibly manage scope;
*partner with suppliers – avoid adversarial relationships, work towards developing the best software;
*create a culture of continuous improvement – allow the process to improve, learn from mistakes and successes.<ref name='Cohen'></ref><ref>M. Poppendieck, T. Poppendieck, 2003, Addison Wesley, Lean Software Development: An Agile Toolkit[[http://www.poppendieck.com/]]</ref>

===Manifesto for the Agile Software development===
A few years before Poppoendieck’s publication, on February 2001,a group of seventeen software developers published in a work called “Manifesto for the Agile Software Development”<ref name='Manifesto'>K. Beck et all., 2001, Manifesto for Agile Software Development[http://www.agilemanifesto.org/]</ref> the main principles of Agile Software development.

From reading these few words it is possible to identify what are the main innovations that ASD introduced in Software development:
[[File:Agilemanifesto.jpg|400px|thumb|right|Manifesto for the Agile Software development<ref name='Manifesto'></ref>]]

*'''“Individuals and interactions”''': with these words founders want to remark the power of human being creativity, and his ability of each man to collaborate with his other similars. The stiffness of Waterfall model is instead represented by “processes and tools” where people was used to follow only what the plan required.
*'''“Working software “''': here is a clear reference to the new way of developing software where at every iteration a working program is realised. This is differently from the previous model in which a working program couldn’t be seen until the end of the project. This feature is put over the “comprehensive documentation” which characterizes especially Waterfall model.
*'''“Customer collaboration”''': it means that there must be a straight relationship between customer and developer in order to define time by time the projects requirements and evaluate every realise.
*'''“Responding to change over following a plan”''' : this sentence encloses the essence of Agile software Development that is to cope with turbulent markets by being flexible and by responding quickly to change. This concept was remarked by the founders in one of the twelve principles which follow the manifesto which says “Welcome changing requirements, even late in development […]”.<ref name='Manifesto'></ref>

=Application=
[[File:Scrum_Framework.png|350px|thumb|right|Scrum Framework]]
There are two concepts that are at the basement of Scrum methodology: '''iterative development''' and '''team working'''. Developing in iterations allow Scrum team to adapt quickly to changing requirements, while working in close location and focusing on communication allow team to make decisions and act on them immediately rather than wait on correspondence.<ref name='Cohen'></ref>

Basically Scrum consists in a sequence of fixed-length iterations called '''Sprint''' that are the fundamental units in which the whole project is divided. As the picture shows Scrum framework is really simple: it starts from a vision like all projects. This idea is converted into a plan during the preliminary meetings where customers and developers identifies the main software requirements and defines the Product Backlog. This represents the entire amount of work that has to be done in order to develop the software. In the next step Product Backlog is divided into several Sprint Backlogs that define which tasks have to be done during the following Sprint. During these iterations the product experiences an incremental development at the end of which it is potentially shippable.

Every Sprint is managed by one or more '''cross-functional and self-organizing teams''' each composed by seven people. There are also other two actors whose task is to be supportive of the software development: one is '''Product Owner''' who mainly handles customers contacts, and the other is '''Scrum Master''' whose main task is to ensure that development team can work without obstacles.

Each sprint usually lasts from 2 to 4 weeks, in this period there are at least one meeting between the Product Owner and Development Team in order to define the main objectives; then there are also short daily meetings held every morning to enhance communication, inform customers, developers, and managers on the status of the project, identify any problems encountered, and keep the entire team focused on a common goal.<ref name='Cohen'></ref>

==Main Actors in Scrum==
===Product Owner===
Product owner is the link between customers and development team, he ensures that deliverables are in line with customers’ expectation and that stakeholders’ interests are fulfilled. He has also the task to fill out customer-centric items (typically '''user stories'''), ranks and prioritizes them before adds them to the '''Product Backlog'''.

Usually development teams have only one Product owner, but differently from the Scrum master, he only takes care of the business side and does not interfere with the scrum team about the technological issues. At the beginning of each Sprint the Product Owner holds a Sprint Planning Meeting to state on which Product Backlog Items Scrum team will go to work during the next Sprint. In this phase he defines what are the most important items for that business, in according to the customer’s needs.

===Development Team===
Development team task is to deliver Product Backlog Items (PBIs) at the end of every Sprint in according with customers’ requirements.
Usually each team is composed by '''cross-functional members''' that allow an all-round software development; the main figures that there must be are a mix of software engineers, architects, programmers, analysts, QA experts, testers, and UI designers.

The size of the team is an important point, the group members' number influences capacity of people to communicate and work together: it is recommended that a scrum team is composed not more than nine people, usually seven.

Another peculiarity of Scrum team is its Self-organization which facilitates members’ creativity and increases team cohesiveness. For this reason it is recommended to not change the members of a team after they have worked together, especially if they had success in their project. After working together team members gain a mutual understanding that increases their capacity of team working, this synergy cannot be acquired if team are continuously changed.

A further point that characterized the good outcomes of a scrum team is location: people are most successful when located in the same room, particularly for the first few Sprints: this facilitates communication and information sharing.

====Team self-organization====
Team self-organization is a crucial point in the scrum methodology. This new concept is well explained by the sentence “it is told developer what needs to be done not how to do it”<ref name='Cohen'></ref>. It means that they can autonomously choose the way to reach commitments.
Furthermore, as it is explained previously, during Sprint execution, team members develop an intrinsic interest in shared goals in this way self-organizing teams can radically outperform larger than traditionally managed teams. It has to be specified that an optimal self-organization takes time: it may be possible that for the first few sprints developers perform worse than when they work in the traditional way.

Some requirements are necessary to gain a good team self-organization:
*members are committed to clear, short-term goals;
*members can gauge the group’s progress;
*members can observe each other’s contribution;
*members feel safe to give each other unvarnished feedback.<ref name='James'>M. James,2010,Scrum Reference Card, Michael James,[[http://scrumreferencecard.com/]]</ref>

Conversely there are some conditions that can hamper self-organization:
*geographical distribution: it is better if the whole team work in a room;
*boss/work dynamics: each member has to consider the others as peer to facilitate a fair communication between them;
*part-time team members;
*interruptions unrelated to Sprint goals.

===Scrum Master===
The scrum master worries that Scrum team can work without obstacles but he has no management authority over them. Essentially he has the aim to:
*create an environment to promote team self-organization;
*support team in the achievement of expected goals;
*ensure that events (e.g. daily Scrum meeting) take place in the right way;
*keep '''Scrum artefacts''' visible ('''Product Backlog''', '''Sprint Backlog''', '''Sprint burndown chart''' …).

==Sprint==
As it is already explained before Sprint (or iteration) is the fundamental unit in which the whole project is divided. It is characterized by a fixed length of 2 weeks or 30 days and by a goal to achieve. At the beginning of each sprint Scrum team , Product Owner , Scrum Master and sometimes also stakeholders hold a meeting, called Sprint Planning meeting. During this encounter it is defined the Sprint Backlog which states what are the goals and requirements of the next Sprint. After this further meetings inside development team will be held in order to define in more detail how achieving the common goals stated in the previous meetings.
==Scrum Meetings==
[[File:Scrum_meetings.png|350px|thumb|right|Scrum Meetings<ref name='James'></ref>]]
Meetings are the fundamental tool used during the whole Scrum process. Usually they are facilitated by the Scrum master who however has no decision-making authority over them. There are different typologies of meetings according to the different phase of the process in which we are.
===Sprint Planning Meeting===
At the beginning of each Sprint, the Product Owner and team hold a Sprint Planning Meeting to define on which '''Product Backlog Items (PBIs)''' they will go to work during the next Sprint. During this meeting "The Product Owner is responsible for declaring which items are the most important to the business" instead "the team is responsible for selecting the amount of work they feel they can implement" (''M. James, 2010'')<ref name='James'></ref>.In this phase in perfect Lean perspective the team “pulls” work from the Product Backlog to the Sprint Backlog. At the end of the meeting the selected items are broken into a provisional list of Sprint task. The maximum time that can be used to do Planning meeting, known as '''timebox''', is of eight hours.

===Daily Scrum and Sprint Execution===
During the sprint every day members of the Scrum team hold a fifteen minutes meeting where they take stock of the situation. Usually they speak about what they did the previous day, which impediments they faced and what they are going to do in the current day. To make these meetings shorter it is better that people are standing.
During sprint execution it is common to find out additional tasks necessary to achieve sprint goal; to keep the control over processes during sprint development it could be useful to maintain a current '''Sprint Task List''', a '''Sprint Burndown Chart''', and an '''Impediments List''': these are some artefacts that allow developer to understand where the project is located.

===Sprint Review Meeting===
At the end of every Sprint it is held a Review meeting where the scrum team has to explain to the Product Owner what they did during the previous sprint. Usually this meeting consists in a live demonstration of the working product increment after which Product Owner states which Items can be considered as done.
Items which are declared not done have to return to the Product Backlog to be ranked and reprioritized by the Product Owner with the help of the Scrum master. Last step of this meeting is to convert stakeholders’ feedback to a new Product Log, this task is consigned to both Product Owner and Scrum Master.
The Sprint Review Meeting is the appropriate meeting for external stakeholders (even end users) to attend.

===Sprint Retrospective Meeting===
During this meeting every member of the scrum team inspects his behaviour to identify some impediments that he faced during the Sprint. There are mainly three kind of impediments in which developers can be involved:
*people who conduct performance evaluation are an obstacles to transparency of the team;
*human tendency of someone in the team to jump to conclusions and propose actions too quickly;
*geographical distribution of the team can be an impediments, team work better if they are delimited in a small place like a room.<ref name='James'></ref>

After identifying all these impediments Scrum master has the task to eliminate them.

===Backlog Refinement Meeting ===
Especially at the beginning of the project "most of the Product Backlog Items (PBIs) need refinement because they are too large and poorly understood" (''M. James, 2010'')<ref name='James'></ref>. In the Backlog Refinement Meeting, the gives an estimation of the remaining work that is required to complete the Items in the Product Backlog and provides other technical informations in order to help the Product Owner to prioritize them.

==Artefacts==
[[File:Product_Backlog_2.png|350px|thumb|right|Product Backlog and Sprint Backlog<ref name='James'></ref>]]
===Product Backlog===

It is defined before the project beginning and then upgraded during the Backlog Refinement meeting ; it is made up by the whole group of items which have to be completed during the project in order to realize the final product. Every item is ranked and constantly reprioritized by the Product Owner. It is important that Product Backlog is visible to the stakeholders.

===Product Backlog Item (PBI)===
An item specifies what has to be done but not how do it. Usually they are written in a User story to be understood also by stakeholders. Every items has a work load of 2-3 days and requires 2-3 people. It represents the basic unit of the Product backlog.
[[File:Sprint_Backlog.png|200px|thumb|right|Sprint Backlog<ref name='James'></ref>]]
===Sprint backlog===

It is defined at the beginning of each sprint during the Sprint Planning meeting where the committed items and the main task that have to be done during the sprint are identified. It has to be visible to the Scrum team and also upgraded during the sprint execution with the additional tasks necessary to achieve the final goal.

===Sprint task===
Every item is divided into several tasks, each of them requires one day or less of work. A sprint task specifies how to achieve what is required by PBI. If the task takes more than one day of work, remaining effort is re-estimated daily, typically in hours.

===Sprint Burndown Chart===
[[File:Sprint_burndown_chart.png|300px|thumb|right|Sprint Burndown Chart<ref name='James'></ref>]]
This tool is used to facilitate self-organization of the team. It indicates the total remaining team task hours within one Sprint. Usually chart shows a decreasing line but if there are some re-estimation it may be possible that line increase for then going down. As picture shows it has a time line in the x axis and the remaining hours of work within one Sprint in the y axis. The advantage of this tool is to show at a first sight at which point of the project you are and the work that is left to complete the Sprint. It is important that this tool is used only as help to Scrum team; in some situations it could become a constraint for developers, in this case Scrum Master has to remove this chart from the room.

=Limitations=
Scrum method was often used in the object-oriented software development. Actually this technique are applied not only on software but also on other products from different sectors like wheelchairs, semiconductors and mortgages.
Scrum has to be used in those projects where people cannot rely on the plan-driven approaches like Waterfall, because of unknown requirements and technology.
[[File:Graph.png|300px|thumb|right|Predictability of a Project<ref name='James'></ref>]]
Conversely if the projects is placed under precise and stable conditions it is better to use one of the traditional model which allow to have a fixed planning over the whole project. In this case Scrum method would involve in a waste of resources and money because he is working on a field that is not its responsibility.

Michael James in his “Scrum Reference card” explains with a simple graphics in which conditions Scrum should be used and which ones are not. James defines the predictability of the projects on the base of two features: knowledge of the requirements and knowledge of the level of technology required. A project which provides known requirements and a known level of technology should be carried out with a plan-driven model. It these conditions are not met it is better to use an empirical approach like Scrum.<ref name='James'></ref>

=References=
<references/>

Scrum Methodology in Agile Software Development

2015-09-28T21:23:17Z

S150821:

Today market is affected by uncertainly and sudden changes, in these conditions most of the models used in the 20th century to develop software are not still appropriate.[[Wikipedia:Waterfall model | Waterfall model]] , probably the most famous between them, is characterized by a stiff structure which can’t cope with the turbulent needs of the actual market.
In recent years many innovations are been enhanced in software engineering with a particular focus on the flexibility of these methods in order to cope with the customers' and markets' needs; surely [[Wikipedia: Agile Software Development |Agile Software Development (ASD)]] is between them.

ASD embraces the principles of [[Wikipedia:Lean Production|Lean Production]] by applying them in software development to avoid waste and increase responsiveness to change. It represents the solution to the unpredictability of the market where the capacity "to welcome change even late in development" (''K. Beck et all, 2001'')<ref name='Manifesto'></ref> is required.
This article deals with Agile Software Development with a particular focus on one of its most used technique : '''Scrum Methodology'''.

=Scrum Methodology=
Scrum is an iterative method used to develop software, it can be placed inside the group of methods which are used in '''ASD'''. This word is taken from rugby and represents that phase of the match where an ordered formation of players, with arms interlocked and heads down, push forward against a similar group to gain possession of the ball<ref name='Cohen'></ref>. This method provides that "work is divided into small chunks to manage complexity and to get early feedback from customers and end users" (''S. Augustine, 2005'')<ref>S. Augustine,2005,Prentice Hall PTR,Managing Agile Projects</ref>; software development is carried out by small working team that allow rapid adjustment during the process and a quick delivery of the final product.

==Agile Software Development==
At the end of the 20th century there were some practitioners who believed that traditional [[Wikipedia:Iterative model |Iterative model]] was not so responsive to market changes. They defined Agile a process which was able to accept change rather than stress predictability.They also believed that to well face customers’ needs development software methods have to respond to change as quickly as it arose rather than prevent changes.<ref name='Cohen'>D.Cohen,M.Lindval,P. Costa,Fraunhofer Center Maryland, Agile Software Development</ref>

It was in these circumstances that practitioners as Mary Poppendieck and Bob Charet started to take inspiration from Lean manufacturing principles and apply them to software development.
These are the main points ,according to Poppendieck, which make Lean Production so successful and that can be applied to software development:

*elimination of waste that does not add value to the customer such as diagram and models that do not add value to the final deliverable;
*minimize inventory such as requirements and design documents;
*maximize flow by using iterative development to reduce development time;
*pull from demand;
*empower workers that means “tell developer what needs to be done not how to do it";
*meet customer requirements – work closely with the customer, allowing them to change their minds
*do it right the first time – test early and refactor when necessary;
*abolish local optimization – flexibly manage scope;
*partner with suppliers – avoid adversarial relationships, work towards developing the best software;
*create a culture of continuous improvement – allow the process to improve, learn from mistakes and successes.<ref name='Cohen'></ref><ref>M. Poppendieck, T. Poppendieck, 2003, Addison Wesley, Lean Software Development: An Agile Toolkit[[http://www.poppendieck.com/]]</ref>

===Manifesto for the Agile Software development===
A few years before Poppoendieck’s publication, on February 2001,a group of seventeen software developers published in a work called “Manifesto for the Agile Software Development”.<ref name='Manifesto'>K. Beck et all., 2001, Manifesto for Agile Software Development[http://www.agilemanifesto.org/]</ref> the main principles of Agile Software development.

From reading these few words it is possible to identify what are the main innovations that ASD introduced in Software development:
[[File:Agilemanifesto.jpg|400px|thumb|right|Manifesto for the Agile Software development<ref name='Manifesto'></ref>]]

*'''“Individuals and interactions”''': with these words founders want to remark the power of human being creativity, and his ability of each man to collaborate with his other similars. The stiffness of Waterfall model is instead represented by “processes and tools” where people was used to follow only what the plan required.
*'''“Working software “''': here is a clear reference to the new way of developing software where at every iteration a working program is realised. This is differently from the previous model in which a working program couldn’t be seen until the end of the project. This feature is put over the “comprehensive documentation” which characterizes especially Waterfall model.
*'''“Customer collaboration”''': it means that there must be a straight relationship between customer and developer in order to define time by time the projects requirements and evaluate every realise.
*'''“Responding to change over following a plan”''' : this sentence encloses the essence of Agile software Development that is to cope with turbulent markets by being flexible and by responding quickly to change. This concept was remarked by the founders in one of the twelve principles which follow the manifesto which says “Welcome changing requirements, even late in development […]”.<ref name='Manifesto'></ref>

=Application=
[[File:Scrum_Framework.png|350px|thumb|right|Scrum Framework]]
There are two concepts that are at the basement of Scrum methodology: '''iterative development''' and '''team working'''. Developing in iterations allow Scrum team to adapt quickly to changing requirements, while working in close location and focusing on communication allow team to make decisions and act on them immediately rather than wait on correspondence.<ref name='Cohen'></ref>

Basically Scrum consists in a sequence of fixed-length iterations called '''Sprint''' that are the fundamental units in which the whole project is divided. As the picture shows Scrum framework is really simple: it starts from a vision like all projects. This idea is converted into a plan during the preliminary meetings where customers and developers identifies the main software requirements and defines the Product Backlog. This represents the entire amount of work that has to be done in order to develop the software. In the next step Product Backlog is divided into several Sprint Backlogs that define which tasks have to be done during the following Sprint. During these iterations the product experiences an incremental development at the end of which it is potentially shippable.

Every Sprint is managed by one or more '''cross-functional and self-organizing teams''' each composed by seven people. There are also other two actors whose task is to be supportive of the software development: one is '''Product Owner''' who mainly handles customers contacts, and the other is '''Scrum Master''' whose main task is to ensure that development team can work without obstacles.

Each sprint usually lasts from 2 to 4 weeks, in this period there are at least one meeting between the Product Owner and Development Team in order to define the main objectives; then there are also short daily meetings held every morning to enhance communication, inform customers, developers, and managers on the status of the project, identify any problems encountered, and keep the entire team focused on a common goal.<ref name='Cohen'></ref>

==Main Actors in Scrum==
===Product Owner===
Product owner is the link between customers and development team, he ensures that deliverables are in line with customers’ expectation and that stakeholders’ interests are fulfilled. He has also the task to fill out customer-centric items (typically '''user stories'''), ranks and prioritizes them before adds them to the '''Product Backlog'''.

Usually development teams have only one Product owner, but differently from the Scrum master, he only takes care of the business side and does not interfere with the scrum team about the technological issues. At the beginning of each Sprint the Product Owner holds a Sprint Planning Meeting to state on which Product Backlog Items Scrum team will go to work during the next Sprint. In this phase he defines what are the most important items for that business, in according to the customer’s needs.

===Development Team===
Development team task is to deliver Product Backlog Items (PBIs) at the end of every Sprint in according with customers’ requirements.
Usually each team is composed by '''cross-functional members''' that allow an all-round software development; the main figures that there must be are a mix of software engineers, architects, programmers, analysts, QA experts, testers, and UI designers.

The size of the team is an important point, the group members' number influences capacity of people to communicate and work together: it is recommended that a scrum team is composed not more than nine people, usually seven.

Another peculiarity of Scrum team is its Self-organization which facilitates members’ creativity and increases team cohesiveness. For this reason it is recommended to not change the members of a team after they have worked together, especially if they had success in their project. After working together team members gain a mutual understanding that increases their capacity of team working, this synergy cannot be acquired if team are continuously changed.

A further point that characterized the good outcomes of a scrum team is location: people are most successful when located in the same room, particularly for the first few Sprints: this facilitates communication and information sharing.

====Team self-organization====
Team self-organization is a crucial point in the scrum methodology. This new concept is well explained by the sentence “it is told developer what needs to be done not how to do it”<ref name='Cohen'></ref>. It means that they can autonomously choose the way to reach commitments.
Furthermore, as it is explained previously, during Sprint execution, team members develop an intrinsic interest in shared goals in this way self-organizing teams can radically outperform larger than traditionally managed teams. It has to be specified that an optimal self-organization takes time: it may be possible that for the first few sprints developers perform worse than when they work in the traditional way.

Some requirements are necessary to gain a good team self-organization:
*members are committed to clear, short-term goals;
*members can gauge the group’s progress;
*members can observe each other’s contribution;
*members feel safe to give each other unvarnished feedback.<ref name='James'>M. James,2010,Scrum Reference Card, Michael James,[[http://scrumreferencecard.com/]]</ref>

Conversely there are some conditions that can hamper self-organization:
*geographical distribution: it is better if the whole team work in a room;
*boss/work dynamics: each member has to consider the others as peer to facilitate a fair communication between them;
*part-time team members;
*interruptions unrelated to Sprint goals.

===Scrum Master===
The scrum master worries that Scrum team can work without obstacles but he has no management authority over them. Essentially he has the aim to:
*create an environment to promote team self-organization;
*support team in the achievement of expected goals;
*ensure that events (e.g. daily Scrum meeting) take place in the right way;
*keep '''Scrum artefacts''' visible ('''Product Backlog''', '''Sprint Backlog''', '''Sprint burndown chart''' …).

==Sprint==
As it is already explained before Sprint (or iteration) is the fundamental unit in which the whole project is divided. It is characterized by a fixed length of 2 weeks or 30 days and by a goal to achieve. At the beginning of each sprint Scrum team , Product Owner , Scrum Master and sometimes also stakeholders hold a meeting, called Sprint Planning meeting. During this encounter it is defined the Sprint Backlog which states what are the goals and requirements of the next Sprint. After this further meetings inside development team will be held in order to define in more detail how achieving the common goals stated in the previous meetings.
==Scrum Meetings==
[[File:Scrum_meetings.png|350px|thumb|right|Scrum Meetings<ref name='James'></ref>]]
Meetings are the fundamental tool used during the whole Scrum process. Usually they are facilitated by the Scrum master who however has no decision-making authority over them. There are different typologies of meetings according to the different phase of the process in which we are.
===Sprint Planning Meeting===
At the beginning of each Sprint, the Product Owner and team hold a Sprint Planning Meeting to define on which '''Product Backlog Items (PBIs)''' they will go to work during the next Sprint. During this meeting "The Product Owner is responsible for declaring which items are the most important to the business" instead "the team is responsible for selecting the amount of work they feel they can implement" (''M. James, 2010'')<ref name='James'></ref>.In this phase in perfect Lean perspective the team “pulls” work from the Product Backlog to the Sprint Backlog. At the end of the meeting the selected items are broken into a provisional list of Sprint task. The maximum time that can be used to do Planning meeting, known as '''timebox''', is of eight hours.

===Daily Scrum and Sprint Execution===
During the sprint every day members of the Scrum team hold a fifteen minutes meeting where they take stock of the situation. Usually they speak about what they did the previous day, which impediments they faced and what they are going to do in the current day. To make these meetings shorter it is better that people are standing.
During sprint execution it is common to find out additional tasks necessary to achieve sprint goal; to keep the control over processes during sprint development it could be useful to maintain a current '''Sprint Task List''', a '''Sprint Burndown Chart''', and an '''Impediments List''': these are some artefacts that allow developer to understand where the project is located.

===Sprint Review Meeting===
At the end of every Sprint it is held a Review meeting where the scrum team has to explain to the Product Owner what they did during the previous sprint. Usually this meeting consists in a live demonstration of the working product increment after which Product Owner states which Items can be considered as done.
Items which are declared not done have to return to the Product Backlog to be ranked and reprioritized by the Product Owner with the help of the Scrum master. Last step of this meeting is to convert stakeholders’ feedback to a new Product Log, this task is consigned to both Product Owner and Scrum Master.
The Sprint Review Meeting is the appropriate meeting for external stakeholders (even end users) to attend.

===Sprint Retrospective Meeting===
During this meeting every member of the scrum team inspects his behaviour to identify some impediments that he faced during the Sprint. There are mainly three kind of impediments in which developers can be involved:
*people who conduct performance evaluation are an obstacles to transparency of the team;
*human tendency of someone in the team to jump to conclusions and propose actions too quickly;
*geographical distribution of the team can be an impediments, team work better if they are delimited in a small place like a room.<ref name='James'></ref>

After identifying all these impediments Scrum master has the task to eliminate them.

===Backlog Refinement Meeting ===
Especially at the beginning of the project "most of the Product Backlog Items (PBIs) need refinement because they are too large and poorly understood" (''M. James, 2010'')<ref name='James'></ref>. In the Backlog Refinement Meeting, the gives an estimation of the remaining work that is required to complete the Items in the Product Backlog and provides other technical informations in order to help the Product Owner to prioritize them.

==Artefacts==
[[File:Product_Backlog_2.png|350px|thumb|right|Product Backlog and Sprint Backlog<ref name='James'></ref>]]
===Product Backlog===

It is defined before the project beginning and then upgraded during the Backlog Refinement meeting ; it is made up by the whole group of items which have to be completed during the project in order to realize the final product. Every item is ranked and constantly reprioritized by the Product Owner. It is important that Product Backlog is visible to the stakeholders.

===Product Backlog Item (PBI)===
An item specifies what has to be done but not how do it. Usually they are written in a User story to be understood also by stakeholders. Every items has a work load of 2-3 days and requires 2-3 people. It represents the basic unit of the Product backlog.
[[File:Sprint_Backlog.png|200px|thumb|right|Sprint Backlog<ref name='James'></ref>]]
===Sprint backlog===

It is defined at the beginning of each sprint during the Sprint Planning meeting where the committed items and the main task that have to be done during the sprint are identified. It has to be visible to the Scrum team and also upgraded during the sprint execution with the additional tasks necessary to achieve the final goal.

===Sprint task===
Every item is divided into several tasks, each of them requires one day or less of work. A sprint task specifies how to achieve what is required by PBI. If the task takes more than one day of work, remaining effort is re-estimated daily, typically in hours.

===Sprint Burndown Chart===
[[File:Sprint_burndown_chart.png|300px|thumb|right|Sprint Burndown Chart<ref name='James'></ref>]]
This tool is used to facilitate self-organization of the team. It indicates the total remaining team task hours within one Sprint. Usually chart shows a decreasing line but if there are some re-estimation it may be possible that line increase for then going down. As picture shows it has a time line in the x axis and the remaining hours of work within one Sprint in the y axis. The advantage of this tool is to show at a first sight at which point of the project you are and the work that is left to complete the Sprint. It is important that this tool is used only as help to Scrum team; in some situations it could become a constraint for developers, in this case Scrum Master has to remove this chart from the room.

=Limitations=
Scrum method was often used in the object-oriented software development. Actually this technique are applied not only on software but also on other products from different sectors like wheelchairs, semiconductors and mortgages.
Scrum has to be used in those projects where people cannot rely on the plan-driven approaches like Waterfall, because of unknown requirements and technology.
[[File:Graph.png|300px|thumb|right|Predictability of a Project<ref name='James'></ref>]]
Conversely if the projects is placed under precise and stable conditions it is better to use one of the traditional model which allow to have a fixed planning over the whole project. In this case Scrum method would involve in a waste of resources and money because he is working on a field that is not its responsibility.

Michael James in his “Scrum Reference card” explains with a simple graphics in which conditions Scrum should be used and which ones are not. James defines the predictability of the projects on the base of two features: knowledge of the requirements and knowledge of the level of technology required. A project which provides known requirements and a known level of technology should be carried out with a plan-driven model. It these conditions are not met it is better to use an empirical approach like Scrum.<ref name='James'></ref>

=References=
<references/>

Talk:Scrum Methodology in Agile Software Development

2015-09-28T21:21:38Z

S150821: /* Answer to reviwer 2 */

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

Talk:Scrum Methodology in Agile Software Development

2015-09-28T21:00:56Z

S150821: /* Answer to reviewer 1 */

== 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 are a link to the “official” site of Scrum reference Card, here you can download it.

Talk:Scrum Methodology in Agile Software Development

2015-09-28T20:55:58Z

S150821: /* 113129's comments: */

== 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
----

'''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

Scrum Methodology in Agile Software Development

2015-09-28T20:13:21Z

S150821:

Today market is affected by uncertainly and sudden changes, in these conditions most of the models used in the 20th century to develop software are not still appropriate.[[Wikipedia:Waterfall model | Waterfall model]] , probably the most famous between them, is characterized by a stiff structure which can’t cope with the turbulent needs of actual market.
In recent years many innovations are been enhanced in software engineering with a particular focus on the flexibility of these methods in order to cope with the customers' and markets' needs; surely [[Wikipedia: Agile Software Development |Agile Software Development (ASD)]] is between them.

ASD embraces the principles of [[Wikipedia:Lean Production|Lean Production]] by applying them in software development to avoid waste and increase responsiveness to change. It represents the solution to the unpredictability of the market where the capacity "to welcome change even late in development" (''K. Beck et all, 2001'')<ref name='Manifesto'></ref> is required.
This article deals with Agile Software Development with a particular focus on one of its most used technique : '''Scrum Methodology'''.

=Scrum Methodology=
Scrum is an iterative method used to develop software, it can be placed inside the group of methods which are used in '''ASD'''. This word is taken from rugby and represents that phase of the match where an ordered formation of players, with arms interlocked and heads down, push forward against a similar group to gain possession of the ball<ref name='Cohen'></ref>. This method provides that "work is divided into small chunks to manage complexity and to get early feedback from customers and end users" (''S. Augustine, 2005'')<ref>S. Augustine,2005,Prentice Hall PTR,Managing Agile Projects</ref>; software development is carried out by small working team that allow rapid adjustment during the process and a quick delivery of the final product.

==Agile Software Development==
At the end of the 20th century there were some practitioners who believed that traditional [[Wikipedia:Iterative model |Iterative model]] was not so responsive to market changes. They defined Agile a process which was able to accept change rather than stress predictability.They also believed that to well face customers’ needs development software methods have to respond to change as quickly as it arose rather than prevent changes.<ref name='Cohen'>D.Cohen,M.Lindval,P. Costa,Fraunhofer Center Maryland, Agile Software Development</ref>

It was in these circumstances that practitioners as Mary Poppendieck and Bob Charet started to take inspiration from Lean manufacturing principles and apply them to software development.
These are the main points ,according to Poppendieck, which make Lean Production so successful and that can be applied to software development:

*elimination of waste that does not add value to the customer such as diagram and models that do not add value to the final deliverable;
*minimize inventory such as requirements and design documents;
*maximize flow by using iterative development to reduce development time;
*pull from demand;
*empower workers that means “tell developer what needs to be done not how to do it";
*meet customer requirements – work closely with the customer, allowing them to change their minds
*do it right the first time – test early and refactor when necessary;
*abolish local optimization – flexibly manage scope;
*partner with suppliers – avoid adversarial relationships, work towards developing the best software;
*create a culture of continuous improvement – allow the process to improve, learn from mistakes and successes.<ref name='Cohen'></ref><ref>M. Poppendieck, T. Poppendieck, 2003, Addison Wesley, Lean Software Development: An Agile Toolkit[[http://www.poppendieck.com/]]</ref>

===Manifesto for the Agile Software development===
A few years before Poppoendieck’s publication, on February 2001,a group of seventeen software developers published in a work called “Manifesto for the Agile Software Development”.<ref name='Manifesto'>K. Beck et all., 2001, Manifesto for Agile Software Development[http://www.agilemanifesto.org/]</ref> the main principles of Agile Software development.

From reading these few words it is possible to identify what are the main innovations that ASD introduced in Software development:
[[File:Agilemanifesto.jpg|400px|thumb|right|Manifesto for the Agile Software development<ref name='Manifesto'></ref>]]

*'''“Individuals and interactions”''': with these words founders want to remark the power of human being creativity, and his ability of each man to collaborate with his other similars. The stiffness of Waterfall model is instead represented by “processes and tools” where people was used to follow only what the plan required.
*'''“Working software “''': here is a clear reference to the new way of developing software where at every iteration a working program is realised. This is differently from the previous model in which a working program couldn’t be seen until the end of the project. This feature is put over the “comprehensive documentation” which characterizes especially Waterfall model.
*'''“Customer collaboration”''': it means that there must be a straight relationship between customer and developer in order to define time by time the projects requirements and evaluate every realise.
*'''“Responding to change over following a plan”''' : this sentence encloses the essence of Agile software Development that is to cope with turbulent markets by being flexible and by responding quickly to change. This concept was remarked by the founders in one of the twelve principles which follow the manifesto which says “Welcome changing requirements, even late in development […]”.<ref name='Manifesto'></ref>

=Application=
[[File:Scrum_Framework.png|350px|thumb|right|Scrum Framework]]
There are two concepts that are at the basement of Scrum methodology: '''iterative development''' and '''team working'''. Developing in iterations allow Scrum team to adapt quickly to changing requirements, while working in close location and focusing on communication allow team to make decisions and act on them immediately rather than wait on correspondence.<ref name='Cohen'></ref>

Basically Scrum consists in a sequence of fixed-length iterations called '''Sprint''' that are the fundamental units in which the whole project is divided. As the picture shows Scrum framework is really simple: it starts from a vision like all projects. This idea is converted into a plan during the preliminary meetings where customers and developers identifies the main software requirements and defines the Product Backlog. This represents the entire amount of work that has to be done in order to develop the software. In the next step Product Backlog is divided into several Sprint Backlogs that define which tasks have to be done during the following Sprint. During these iterations the product experiences an incremental development at the end of which it is potentially shippable.

Every Sprint is managed by one or more '''cross-functional and self-organizing teams''' each composed by seven people. There are also other two actors whose task is to be supportive of the software development: one is '''Product Owner''' who mainly handles customers contacts, and the other is '''Scrum Master''' whose main task is to ensure that development team can work without obstacles.

Each sprint usually lasts from 2 to 4 weeks, in this period there are at least one meeting between the Product Owner and Development Team in order to define the main objectives; then there are also short daily meetings held every morning to enhance communication, inform customers, developers, and managers on the status of the project, identify any problems encountered, and keep the entire team focused on a common goal.<ref name='Cohen'></ref>

==Main Actors in Scrum==
===Product Owner===
Product owner is the link between customers and development team, he ensures that deliverables are in line with customers’ expectation and that stakeholders’ interests are fulfilled. He has also the task to fill out customer-centric items (typically '''user stories'''), ranks and prioritizes them before adds them to the '''Product Backlog'''.

Usually development teams have only one Product owner, but differently from the Scrum master, he only takes care of the business side and does not interfere with the scrum team about the technological issues. At the beginning of each Sprint the Product Owner holds a Sprint Planning Meeting to state on which Product Backlog Items Scrum team will go to work during the next Sprint. In this phase he defines what are the most important items for that business, in according to the customer’s needs.

===Development Team===
Development team task is to deliver Product Backlog Items (PBIs) at the end of every Sprint in according with customers’ requirements.
Usually each team is composed by '''cross-functional members''' that allow an all-round software development; the main figures that there must be are a mix of software engineers, architects, programmers, analysts, QA experts, testers, and UI designers.

The size of the team is an important point, the group members' number influences capacity of people to communicate and work together: it is recommended that a scrum team is composed not more than nine people, usually seven.

Another peculiarity of Scrum team is its Self-organization which facilitates members’ creativity and increases team cohesiveness. For this reason it is recommended to not change the members of a team after they have worked together, especially if they had success in their project. After working together team members gain a mutual understanding that increases their capacity of team working, this synergy cannot be acquired if team are continuously changed.

A further point that characterized the good outcomes of a scrum team is location: people are most successful when located in the same room, particularly for the first few Sprints: this facilitates communication and information sharing.

====Team self-organization====
Team self-organization is a crucial point in the scrum methodology. This new concept is well explained by the sentence “it is told developer what needs to be done not how to do it”<ref name='Cohen'></ref>. It means that they can autonomously choose the way to reach commitments.
Furthermore, as it is explained previously, during Sprint execution, team members develop an intrinsic interest in shared goals in this way self-organizing teams can radically outperform larger than traditionally managed teams. It has to be specified that an optimal self-organization takes time: it may be possible that for the first few sprints developers perform worse than when they work in the traditional way.

Some requirements are necessary to gain a good team self-organization:
*members are committed to clear, short-term goals;
*members can gauge the group’s progress;
*members can observe each other’s contribution;
*members feel safe to give each other unvarnished feedback.<ref name='James'>M. James,2010,Scrum Reference Card, Michael James,[[http://scrumreferencecard.com/]]</ref>

Conversely there are some conditions that can hamper self-organization:
*geographical distribution: it is better if the whole team work in a room;
*boss/work dynamics: each member has to consider the others as peer to facilitate a fair communication between them;
*part-time team members;
*interruptions unrelated to Sprint goals.

===Scrum Master===
The scrum master worries that Scrum team can work without obstacles but he has no management authority over them. Essentially he has the aim to:
*create an environment to promote team self-organization;
*support team in the achievement of expected goals;
*ensure that events (e.g. daily Scrum meeting) take place in the right way;
*keep '''Scrum artefacts''' visible ('''Product Backlog''', '''Sprint Backlog''', '''Sprint burndown chart''' …).

==Sprint==
As it is already explained before Sprint (or iteration) is the fundamental unit in which the whole project is divided. It is characterized by a fixed length of 2 weeks or 30 days and by a goal to achieve. At the beginning of each sprint Scrum team , Product Owner , Scrum Master and sometimes also stakeholders hold a meeting, called Sprint Planning meeting. During this encounter it is defined the Sprint Backlog which states what are the goals and requirements of the next Sprint. After this further meetings inside development team will be held in order to define in more detail how achieving the common goals stated in the previous meetings.
==Scrum Meetings==
[[File:Scrum_meetings.png|350px|thumb|right|Scrum Meetings<ref name='James'></ref>]]
Meetings are the fundamental tool used during the whole Scrum process. Usually they are facilitated by the Scrum master who however has no decision-making authority over them. There are different typologies of meetings according to the different phase of the process in which we are.
===Sprint Planning Meeting===
At the beginning of each Sprint, the Product Owner and team hold a Sprint Planning Meeting to define on which '''Product Backlog Items (PBIs)''' they will go to work during the next Sprint. During this meeting "The Product Owner is responsible for declaring which items are the most important to the business" instead "the team is responsible for selecting the amount of work they feel they can implement" (''M. James, 2010'')<ref name='James'></ref>.In this phase in perfect Lean perspective the team “pulls” work from the Product Backlog to the Sprint Backlog. At the end of the meeting the selected items are broken into a provisional list of Sprint task. The maximum time that can be used to do Planning meeting, known as '''timebox''', is of eight hours.

===Daily Scrum and Sprint Execution===
During the sprint every day members of the Scrum team hold a fifteen minutes meeting where they take stock of the situation. Usually they speak about what they did the previous day, which impediments they faced and what they are going to do in the current day. To make these meetings shorter it is better that people are standing.
During sprint execution it is common to find out additional tasks necessary to achieve sprint goal; to keep the control over processes during sprint development it could be useful to maintain a current '''Sprint Task List''', a '''Sprint Burndown Chart''', and an '''Impediments List''': these are some artefacts that allow developer to understand where the project is located.

===Sprint Review Meeting===
At the end of every Sprint it is held a Review meeting where the scrum team has to explain to the Product Owner what they did during the previous sprint. Usually this meeting consists in a live demonstration of the working product increment after which Product Owner states which Items can be considered as done.
Items which are declared not done have to return to the Product Backlog to be ranked and reprioritized by the Product Owner with the help of the Scrum master. Last step of this meeting is to convert stakeholders’ feedback to a new Product Log, this task is consigned to both Product Owner and Scrum Master.
The Sprint Review Meeting is the appropriate meeting for external stakeholders (even end users) to attend.

===Sprint Retrospective Meeting===
During this meeting every member of the scrum team inspects his behaviour to identify some impediments that he faced during the Sprint. There are mainly three kind of impediments in which developers can be involved:
*people who conduct performance evaluation are an obstacles to transparency of the team;
*human tendency of someone in the team to jump to conclusions and propose actions too quickly;
*geographical distribution of the team can be an impediments, team work better if they are delimited in a small place like a room.<ref name='James'></ref>

After identifying all these impediments Scrum master has the task to eliminate them.

===Backlog Refinement Meeting ===
Especially at the beginning of the project "most of the Product Backlog Items (PBIs) need refinement because they are too large and poorly understood" (''M. James, 2010'')<ref name='James'></ref>. In the Backlog Refinement Meeting, the gives an estimation of the remaining work that is required to complete the Items in the Product Backlog and provides other technical informations in order to help the Product Owner to prioritize them.

==Artefacts==
[[File:Product_Backlog_2.png|350px|thumb|right|Product Backlog and Sprint Backlog<ref name='James'></ref>]]
===Product Backlog===

It is defined before the project beginning and then upgraded during the Backlog Refinement meeting ; it is made up by the whole group of items which have to be completed during the project in order to realize the final product. Every item is ranked and constantly reprioritized by the Product Owner. It is important that Product Backlog is visible to the stakeholders.

===Product Backlog Item (PBI)===
An item specifies what has to be done but not how do it. Usually they are written in a User story to be understood also by stakeholders. Every items has a work load of 2-3 days and requires 2-3 people. It represents the basic unit of the Product backlog.
[[File:Sprint_Backlog.png|200px|thumb|right|Sprint Backlog<ref name='James'></ref>]]
===Sprint backlog===

It is defined at the beginning of each sprint during the Sprint Planning meeting where the committed items and the main task that have to be done during the sprint are identified. It has to be visible to the Scrum team and also upgraded during the sprint execution with the additional tasks necessary to achieve the final goal.

===Sprint task===
Every item is divided into several tasks, each of them requires one day or less of work. A sprint task specifies how to achieve what is required by PBI. If the task takes more than one day of work, remaining effort is re-estimated daily, typically in hours.

===Sprint Burndown Chart===
[[File:Sprint_burndown_chart.png|300px|thumb|right|Sprint Burndown Chart<ref name='James'></ref>]]
This tool is used to facilitate self-organization of the team. It indicates the total remaining team task hours within one Sprint. Usually chart shows a decreasing line but if there are some re-estimation it may be possible that line increase for then going down. As picture shows it has a time line in the x axis and the remaining hours of work within one Sprint in the y axis. The advantage of this tool is to show at a first sight at which point of the project you are and the work that is left to complete the Sprint. It is important that this tool is used only as help to Scrum team; in some situations it could become a constraint for developers, in this case Scrum Master has to remove this chart from the room.

=Limitations=
Scrum method was often used in the object-oriented software development. Actually this technique are applied not only on software but also on other products from different sectors like wheelchairs, semiconductors and mortgages.
Scrum has to be used in those projects where people cannot rely on the plan-driven approaches like Waterfall, because of unknown requirements and technology.
[[File:Graph.png|300px|thumb|right|Predictability of a Project<ref name='James'></ref>]]
Conversely if the projects is placed under precise and stable conditions it is better to use one of the traditional model which allow to have a fixed planning over the whole project. In this case Scrum method would involve in a waste of resources and money because he is working on a field that is not its responsibility.

Michael James in his “Scrum Reference card” explains with a simple graphics in which conditions Scrum should be used and which ones are not. James defines the predictability of the projects on the base of two features: knowledge of the requirements and knowledge of the level of technology required. A project which provides known requirements and a known level of technology should be carried out with a plan-driven model. It these conditions are not met it is better to use an empirical approach like Scrum.<ref name='James'></ref>

=References=
<references/>

Scrum Methodology in Agile Software Development

2015-09-28T20:05:48Z

S150821:

Today market is affected by uncertainly and sudden changes, in these conditions most of the models used in the 20th century to develop software are not still appropriate.[[Wikipedia:Waterfall model | Waterfall model]] , probably the most famous between them, is characterized by a stiff structure which can’t cope with the turbulent needs of actual market.
In recent years many innovations are been enhanced in software engineering with a particular focus on the flexibility of these methods in order to cope with the customers' and markets' needs; surely [[Wikipedia: Agile Software Development |Agile Software Development (ASD)]] is between them.

ASD embraces the principles of [[Wikipedia:Lean Production|Lean Production]] by applying them in software development to avoid waste and increase responsiveness to change. It represents the solution to the unpredictability of the market where the capacity "to welcome change even late in development" (''K. Beck et all, 2001'')<ref name='Manifesto'></ref> is required.
This article deals with Agile Software Development with a particular focus on one of its most used technique : '''Scrum Methodology'''.

=Scrum Methodology=
Scrum is an iterative method used to develop software, it can be placed inside the group of methods which are used in '''ASD'''. This word is taken from rugby and represents that phase of the match where an ordered formation of players, with arms interlocked and heads down, push forward against a similar group to gain possession of the ball<ref name='Cohen'></ref>. This method provides that "work is divided into small chunks to manage complexity and to get early feedback from customers and end users" (''S. Augustine, 2005'')<ref>S. Augustine,2005,Prentice Hall PTR,Managing Agile Projects</ref>; software development is carried out by small working team that allow rapid adjustment during the process and a quick delivery of the final product.

==Agile Software Development==
At the end of the 20th century there were some practitioners who believed that traditional [[Wikipedia:Iterative model |Iterative model]] was not so responsive to market changes. They defined Agile a process which was able to accept change rather than stress predictability.They also believed that to well face customers’ needs development software methods have to respond to change as quickly as it arose rather than prevent changes.<ref name='Cohen'>D.Cohen,M.Lindval,P. Costa,Fraunhofer Center Maryland, Agile Software Development</ref>

It was in these circumstances that practitioners as Mary Poppendieck and Bob Charet started to take inspiration from Lean manufacturing principles and apply them to software development.
These are the main points ,according to Poppendieck, which make Lean Production so successful and that can be applied to software development:

*elimination of waste that does not add value to the customer such as diagram and models that do not add value to the final deliverable;
*minimize inventory such as requirements and design documents;
*maximize flow by using iterative development to reduce development time;
*pull from demand;
*empower workers that means “tell developer what needs to be done not how to do it";
*meet customer requirements – work closely with the customer, allowing them to change their minds
*do it right the first time – test early and refactor when necessary;
*abolish local optimization – flexibly manage scope;
*partner with suppliers – avoid adversarial relationships, work towards developing the best software;
*create a culture of continuous improvement – allow the process to improve, learn from mistakes and successes.<ref name='Cohen'></ref><ref>M. Poppendieck, T. Poppendieck, 2003, Addison Wesley, Lean Software Development: An Agile Toolkit[[http://www.poppendieck.com/]]</ref>

===Manifesto for the Agile Software development===
A few years before Poppoendieck’s publication, on February 2001,a group of seventeen software developers published in a work called “Manifesto for the Agile Software Development”.<ref name='Manifesto'>K. Beck et all., 2001, Manifesto for Agile Software Development[http://www.agilemanifesto.org/]</ref> the main principles of Agile Software development.

From reading these few words it is possible to identify what are the main innovations that ASD introduced in Software development:
[[File:Agilemanifesto.jpg|400px|thumb|right|Manifesto for the Agile Software development<ref name='Manifesto'></ref>]]

*'''“Individuals and interactions”''': with these words founders want to remark the power of human being creativity, and his ability of each man to collaborate with his other similars. The stiffness of Waterfall model is instead represented by “processes and tools” where people was used to follow only what the plan required.
*'''“Working software “''': here is a clear reference to the new way of developing software where at every iteration a working program is realised. This is differently from the previous model in which a working program couldn’t be seen until the end of the project. This feature is put over the “comprehensive documentation” which characterizes especially Waterfall model.
*'''“Customer collaboration”''': it means that there must be a straight relationship between customer and developer in order to define time by time the projects requirements and evaluate every realise.
*'''“Responding to change over following a plan”''' : this sentence encloses the essence of Agile software Development that is to cope with turbulent markets by being flexible and by responding quickly to change. This concept was remarked by the founders in one of the twelve principles which follow the manifesto which says “Welcome changing requirements, even late in development […]”.<ref name='Manifesto'></ref>

=Application=
[[File:Scrum_Framework.png|350px|thumb|right|Scrum Framework]]
There are two concepts that are at the basement of Scrum methodology: '''iterative development''' and '''team working'''. Developing in iterations allow Scrum team to adapt quickly to changing requirements, while working in close location and focusing on communication allow team to make decisions and act on them immediately rather than wait on correspondence.<ref name='Cohen'></ref>

Basically Scrum consists in a sequence of fixed-length iterations called '''Sprint''' that are the fundamental units in which the whole project is divided. As the picture shows Scrum framework is really simple: it starts from a vision like all projects. This idea is converted into a plan during the preliminary meetings where customers and developers identifies the main software requirements and defines the Product Backlog. This represents the entire amount of work that has to be done in order to develop the software. In the next step Product Backlog is divided into several Sprint Backlogs that define which tasks have to be done during the following Sprint. During these iterations the product experiences an incremental development at the end of which it is potentially shippable.

Every Sprint is managed by one or more '''cross-functional and self-organizing teams''' each composed by seven people. There are also other two actors whose task is to be supportive of the software development: one is '''Product Owner''' who mainly handles customers contacts, and the other is '''Scrum Master''' whose main task is to ensure that development team can work without obstacles.

Each sprint usually lasts from 2 to 4 weeks, in this period there are at least one meeting between the Product Owner and Development Team in order to define the main objectives; then there are also short daily meetings held every morning to enhance communication, inform customers, developers, and managers on the status of the project, identify any problems encountered, and keep the entire team focused on a common goal.<ref name='Cohen'></ref>

==Main Actors in Scrum==
===Product Owner===
Product owner is the link between customers and development team, he ensures that deliverables are in line with customers’ expectation and that stakeholders’ interests are fulfilled. He has also the task to fill out customer-centric items (typically '''user stories'''), ranks and prioritizes them before adds them to the '''Product Backlog'''.

Usually development teams have only one Product owner, but differently from the Scrum master, he only takes care of the business side and does not interfere with the scrum team about the technological issues. At the beginning of each Sprint the Product Owner holds a Sprint Planning Meeting to state on which Product Backlog Items Scrum team will go to work during the next Sprint. In this phase he defines what are the most important items for that business, in according to the customer’s needs.

===Development Team===
Development team task is to deliver Product Backlog Items (PBIs) at the end of every Sprint in according with customers’ requirements.
Usually each team is composed by '''cross-functional members''' that allow an all-round software development; the main figures that there must be are a mix of software engineers, architects, programmers, analysts, QA experts, testers, and UI designers.

The size of the team is an important point, the group members' number influences capacity of people to communicate and work together: it is recommended that a scrum team is composed not more than nine people, usually seven.

Another peculiarity of Scrum team is its Self-organization which facilitates members’ creativity and increases team cohesiveness. For this reason it is recommended to not change the members of a team after they have worked together, especially if they had success in their project. After working together team members gain a mutual understanding that increases their capacity of team working, this synergy cannot be acquired if team are continuously changed.

A further point that characterized the good outcomes of a scrum team is location: people are most successful when located in the same room, particularly for the first few Sprints: this facilitates communication and information sharing.

====Team self-organization====
Team self-organization is a crucial point in the scrum methodology. This new concept is well explained by the sentence “it is told developer what needs to be done not how to do it”<ref name='Cohen'></ref>. It means that they can autonomously choose the way to reach commitments.
Furthermore, as it is explained previously, during Sprint execution, team members develop an intrinsic interest in shared goals in this way self-organizing teams can radically outperform larger than traditionally managed teams. It has to be specified that an optimal self-organization takes time: it may be possible that for the first few sprints developers perform worse than when they work in the traditional way.

Some requirements are necessary to gain a good team self-organization:
*members are committed to clear, short-term goals;
*members can gauge the group’s progress;
*members can observe each other’s contribution;
*members feel safe to give each other unvarnished feedback.<ref name='James'>M. James,2010,Scrum Reference Card, Michael James,[[http://scrumreferencecard.com/]]</ref>

Conversely there are some conditions that can hamper self-organization:
*geographical distribution: it is better if the whole team work in a room;
*boss/work dynamics: each member has to consider the others as peer to facilitate a fair communication between them;
*part-time team members;
*interruptions unrelated to Sprint goals.

===Scrum Master===
The scrum master worries that Scrum team can work without obstacles but he has no management authority over them. Essentially he has the aim to:
*create an environment to promote team self-organization;
*support team in the achievement of expected goals;
*ensure that events (e.g. daily Scrum meeting) take place in the right way;
*keep '''Scrum artefacts''' visible ('''Product Backlog''', '''Sprint Backlog''', '''Sprint burndown chart''' …).

==Sprint==
As it is already explained before Sprint (or iteration) is the fundamental unit in which the whole project is divided. It is characterized by a fixed length of 2 weeks or 30 days and by a goal to achieve. At the beginning of each sprint Scrum team , Product Owner , Scrum Master and sometimes also stakeholders hold a meeting, called Sprint Planning meeting. During this encounter it is defined the Sprint Backlog which states what are the goals and requirements of the next Sprint. After this further meetings inside development team will be held in order to define in more detail how achieving the common goals stated in the previous meetings.
==Scrum Meetings==
[[File:Scrum_meetings.png|350px|thumb|right|Scrum Meetings<ref name='James'></ref>]]
Meeting are a fundamental tool used during the whole Scrum process. Usually they are facilitated by the Scrum master who has no decision-making authority over them . There are different typologies of meetings according to the different phase of the process in which we are.
===Sprint Planning Meeting===
At the beginning of each Sprint, the Product Owner and team hold a Sprint Planning Meeting to define on which '''Product Backlog Items (PBIs)''' they will go to work during the next Sprint. "The Product Owner is responsible for declaring which items are the most important to the business. The team is responsible for selecting the amount of work they feel they can implement" (''M. James, 2010'')<ref name='James'></ref>.In this phase in perfect Lean perspective the team “pulls” work from the Product Backlog to the Sprint Backlog. At the end of the meeting the selected items are broken into a provisional list of Sprint task. The maximum time that can be used to do Planning meeting, known as '''timebox''', is of eight hours.

===Daily Scrum and Sprint Execution===
During the sprint every day members of the Scrum team hold a fifteen minutes meeting where they take stock of the situation. Usually they speak about what they did previous day, which impediments they faced and what they are going to do in the current day. To make these meetings shorter it is better that people are standing.
During sprint execution it is common to find out additional tasks necessary to achieve sprint goal; to keep the control over processes during sprint development it could be useful to maintain a current '''Sprint Task List''', a '''Sprint Burndown Chart''', and an '''Impediments List''': these are some artefacts that allow developer to understand where the project is located.

===Sprint Review Meeting===
At the end of every Sprint it is held a Review meeting where the scrum team has to explain to the Product Owner what they did during the previous sprint. Usually this meeting consists in a live demonstration of the working product increment after which Product Owner states which Items can be considered as done.
Items which are declared not done have to return to the Product Backlog to be ranked and reprioritized by the Product Owner with the help of the Scrum master. Last step of this meeting is to convert stakeholders’ feedback to a new Product Log, this task is consigned to both Product Owner and Scrum Master.
The Sprint Review Meeting is the appropriate meeting for external stakeholders (even end users) to attend.

===Sprint Retrospective Meeting===
During this meeting every member of the scrum team inspects his behaviour to identify some impediments that he faced during Sprint. There are mainly three kind of impediments in which developers can be involved:
*people who conduct performance evaluation are an obstacles to transparency of the team;
*human tendency of someone in the team to jump to conclusions and propose actions too quickly;
*geographical distribution of the team can be an impediments, team work better if they are delimited in a small place like a room.<ref name='James'></ref>

After identifying all these impediments Scrum master has the task to eliminate them.

===Backlog Refinement Meeting ===
Especially at the beginning of the project "most of the Product Backlog Items (PBIs) need refinement because they are too large and poorly understood" (''M. James, 2010'')<ref name='James'></ref>. In the Backlog Refinement Meeting, the team gave an estimation of the work left to complete Items in the Product Backlog and provides other technical information to help the Product Owner prioritize them.

==Artefacts==
[[File:Product_Backlog_2.png|350px|thumb|right|Product Backlog and Sprint Backlog<ref name='James'></ref>]]
===Product Backlog===

It is defined before the project beginning and then upgraded during the Backlog Refinement meeting ; it is made up by the whole group of items which have to be completed during the project in order to realize the final product. Every item is ranked and constantly reprioritized by the Product Owner. It is important that Product Backlog Is visible to the stakeholders.

===Product Backlog Item (PBI)===
An item specifies what has to be done but not how do it. Usually they are written in a User story to be understood also by stakeholders. Every items has a work load of 2-3 days and requires 2-3 people. It represents the basic unit of Product backlog.
[[File:Sprint_Backlog.png|200px|thumb|right|Sprint Backlog<ref name='James'></ref>]]
===Sprint backlog===

It is defined at the beginning of each sprint during the Sprint Planning meeting where committed items and the main task that have to be done during the sprint are identified. It has to be visible to Scrum team and it can be upgraded during the sprint execution with additional task necessary to achieve the final goal.

===Sprint task===
Every item is divided into several tasks, each of them requires one day or less of work. A sprint task specifies how to achieve what is required by PBI. If the task takes more than one day of work, remaining effort is re-estimated daily, typically in hours.

===Sprint Burndown Chart===
[[File:Sprint_burndown_chart.png|300px|thumb|right|Sprint Burndown Chart<ref name='James'></ref>]]
This tool is used to facilitate self-organization of the team. It indicates the total remaining team task hours within one Sprint. Usually chart shows a decreasing line but if there are some re-estimation it may be possible that line increase for then going down. As picture shows it has a time line in the x axis and the remaining hours of work within one Sprint in the y axis. The advantage of this tool is to show at a first sight at which point of the project you are and the work that is left to complete the Sprint. It is important that this tool is used only as help to Scrum team; in some situations it could become a constraint for developers, in this case Scrum Master has to remove this chart from the room.

=Limitations=
Scrum method was often used in the object-oriented software development. Actually this technique are applied not only on software but also on other products from different sectors like wheelchairs, semiconductors and mortgages.
Scrum has to be used in those projects where people cannot rely on the plan-driven approaches like Waterfall, because of unknown requirements and technology.
[[File:Graph.png|300px|thumb|right|Predictability of a Project<ref name='James'></ref>]]
Conversely if the projects is placed under precise and stable conditions it is better to use one of the traditional model which allow to have a fixed planning over the whole project. In this case Scrum method would involve in a waste of resources and money because he is working on a field that is not its responsibility.

Michael James in his “Scrum Reference card” explains with a simple graphics in which conditions Scrum should be used and which ones are not. James defines the predictability of the projects on the base of two features: knowledge of the requirements and knowledge of the level of technology required. A project which provides known requirements and a known level of technology should be carried out with a plan-driven model. It these conditions are not met it is better to use an empirical approach like Scrum.<ref name='James'></ref>

=References=
<references/>

Scrum Methodology in Agile Software Development

2015-09-28T19:28:50Z

S150821: /* Artefacts */

Today market is affected by uncertainly and sudden changes, in these conditions most of the models used in the 20th century to develop software are not still appropriate.[[Wikipedia:Waterfall model | Waterfall model]] , probably the most famous between them, is characterized by a stiff structure which can’t cope with the turbulent needs of actual market.
In recent years many innovations are been enhanced in software engineering with a particular focus on the flexibility of these methods in order to cope with the customers' and markets' needs; surely [[Wikipedia: Agile Software Development |Agile Software Development (ASD)]] is between them.

ASD embraces the principles of lean production by applying them in software development to avoid waste and increase responsiveness to change. It represents the solution to the unpredictability of the market where the capacity "to welcome change even late in development" (''K. Beck et all, 2001'')<ref name='Manifesto'></ref> to satisfy customers is required.
This article deals with Agile Software Development with a particular focus on one of its most used technique : '''Scrum Methodology'''.

=Scrum Methodology=
Scrum is an iterative method used to develop software, it can be placed inside the group of methods which are used in '''ASD'''. This word is taken from rugby and represents that phase of the match where an ordered formation of players, with arms interlocked and heads down, push forward against a similar group to gain possession of the ball<ref name='Cohen'></ref>. This method provides that "work is divided into small chunks to manage complexity and to get early feedback from customers and end users" (''S. Augustine, 2005'')<ref>S. Augustine,2005,Prentice Hall PTR,Managing Agile Projects</ref>; software development is carried out by small working team that allow rapid adjustment during the process and a quick delivery of the final product.

==Agile Software Development==
Some practitioners believed that traditional [[Wikipedia:Iterative model |Iterative model]] was not so responsive to changes that market required. They thought that to be Agile a process needs to accept change rather than stress predictability and that methods used to develop software has to respond to change as quickly as it arose rather than prevent changes.<ref name='Cohen'>D.Cohen,M.Lindval,P. Costa,Fraunhofer Center Maryland, Agile Software Development</ref>

It was in these circumstances that practitioners as Mary Poppendieck and Bob Charet started to take inspiration from Lean manufacturing principles and apply them to software development.
These are the main points ,according to Poppendieck, which make Lean Production so successful and that can be applied to software development:

*elimination of waste that does not add value to the customer such as diagram and models that do not add value to the final deliverable;
*minimize inventory such as requirements and design documents;
*maximize flow by using iterative development to reduce development time;
*pull from demand;
*empower workers that means “tell developer what needs to be done not how to do it";
*meet customer requirements – work closely with the customer, allowing them to change their minds
*do it right the first time – test early and refactor when necessary;
*abolish local optimization – flexibly manage scope;
*partner with suppliers – avoid adversarial relationships, work towards developing the best software;
*create a culture of continuous improvement – allow the process to improve, learn from mistakes and successes.<ref name='Cohen'></ref><ref>M. Poppendieck, T. Poppendieck, 2003, Addison Wesley, Lean Software Development: An Agile Toolkit[[http://www.poppendieck.com/]]</ref>

===Manifesto for the Agile Software development===
A few years before Poppoendieck’s publication on February 2001 main principles of Agile Software development were stated by a group of seventeen software developers which published “Manifesto for the Agile Software Development”.<ref name='Manifesto'>K. Beck et all., 2001, Manifesto for Agile Software Development[http://www.agilemanifesto.org/]</ref>

From reading these few words it is possible to identify what are the main innovations that ASD introduced in Software development:
[[File:Agilemanifesto.jpg|400px|thumb|right|Manifesto for the Agile Software development<ref name='Manifesto'></ref>]]

*'''“Individuals and interactions”''' : with these words founders want to remark the power of human being creativity, and his ability to collaborate with other similar. The stiffness of Waterfall model is instead represented by “processes and tools” where people has to follow only what the plan requires.
*'''“Working software “''' : there is a clear reference to the new way to develop software where at every iteration a working program is realised, differently from the earlier model in which a working program couldn’t be seen until the end of the project. This feature is put over the “comprehensive documentation” which characterizes especially Waterfall model.
*'''“Customer collaboration”''' : means that there must be a straight relationship between customer and developer in order to define time by time the projects requirements and evaluate every realise.
*'''“Responding to change over following a plan”''' : this sentence encloses the essence of Agile software Development that is to cope with turbulent markets by being flexible and by responding quickly to change, instead of being bound by planning. This concept is remarked by the founders in one of the twelve principles which follow the manifesto which says “Welcome changing requirements, even late in development […]”.

=Application=
[[File:Scrum_Framework.png|350px|thumb|right|Scrum Framework]]
There are two concepts that are at the basement of Scrum methodology: '''iterative development''' and '''team working'''. Developing in iterations allow Scrum team to adapt quickly to changing requirements, while working in close location and focusing on communication allow team to make decisions and act on them immediately rather than wait on correspondence.<ref name='Cohen'></ref>

Basically Scrum consists in a sequence of fixed-length iterations called [[Sprint:http://apppm.man.dtu.dk/index.php?title=Scrum_Methodology_in_Agile_Software_Development&action=submit#Sprint|Sprint]] managed by one or more '''cross-functional and self-organizing teams''' each composed by seven people that aim at a common goal and that usually work only on the software development. There are instead other two actors that manage all things that are in support of the development process: one is '''Product Owner''' who mainly handles customers contacts and the other is '''Scrum Master''' whose main task is to ensure that development team can work without obstacles.

Each sprint usually lasts from 2 to 4 weeks, in this period there are at least one meeting between the Product Owner and Development Team to define the main objectives; then there are short daily meetings held every morning to enhance communication and inform customers, developers, and managers on the status of the project, identify any problems encountered, and keep the entire team focused on a common goal.<ref name='Cohen'></ref>

==Main Actors in Scrum==
===Product Owner===
Product owner is the link between customers and development team, he ensures that deliverables are in line with customers’ expectation and that stakeholders’ interests are fulfilled. He has also the task to fill out customer-centric items (typically '''user stories'''), ranks and prioritizes them before adds them to '''Product Backlog'''.

Usually development teams have only one Product owner, but differently from the Scrum master, he only takes care of the business side and does not interfere with the scrum team about the technological issues. At the beginning of each Sprint the Product Owner holds a Sprint Planning Meeting to state on which Product Backlog Items Scrum team will go to work during the next Sprint. In this phase he defines what are the most important items for that business, in according to customer’s needs.

===Development Team===
Development team task is to provide Product Backlog Items (PBIs) at the end of every Sprint in according with customers’ requirements after negotiating commitments with the Product Owner.
Usually each team is composed by '''cross-functional members''' that allow an all-round software development; the main figures that there must be are a mix of software engineers, architects, programmers, analysts, QA experts, testers, and UI designers.

The size of the team is an important point, the group members' number influences capacity of people to communicate and work together: it is recommended that a scrum team is composed not more than nine people, usually seven.

Another important characteristic is the Self-organization of the group which facilitates members’ creativity and increases team cohesiveness: for this reason it is better to not change members of a team after they have worked together, especially if they had success in their project. After working together team members gain a mutual understanding that increases their capacity of team working, this synergy cannot be acquired if team are continuously changed.

A further point that characterized the good outcomes of a scrum team is location: people are most successful when located in the same room, particularly for the first few Sprints: this facilitates communication and information sharing.

====Team self-organization====
Team self-organization is a crucial point in the scrum methodology : with this concept it means that “it is told developer what needs to be done not how to do it”<ref name='Cohen'></ref>, they can autonomously choose the way to reach commitments.
As it is said previously during Sprint execution, team members develop an intrinsic interest in shared goals and learn to manage each other to achieve them, for this reason self-organizing teams can radically outperform larger than traditionally managed teams. It has to be specified that an optimal self-organization takes time: it may be possible that for the first few sprints developers perform worse than when they work in the traditional way.

Some requirements are necessary to gain a good team self-organization:
*members are committed to clear, short-term goals;
*members can gauge the group’s progress;
*members can observe each other’s contribution;
*members feel safe to give each other unvarnished feedback.<ref name='James'>M. James,2010,Scrum Reference Card, Michael James,[[http://scrumreferencecard.com/]]</ref>

Conversely there are some conditions that can hamper self-organization:
*geographical distribution: it is better if the whole team work in a room;
*boss/work dynamics: each member has to consider the others as peer to facilitate a fair communication between them;
*part-time team members;
*interruptions unrelated to Sprint goals.

===Scrum Master===
The scrum master worries that Scrum team can work without obstacles but he has no management authority over them. Essentially he has the aim to:
*create an environment to promote team self-organization;
*support team in the achievement of expected goals;
*ensure that events (e.g. daily Scrum meeting) take place in the right way;
*keep '''Scrum artefacts''' visible ('''Product Backlog''', '''Sprint Backlog''', '''Sprint burndown chart''' …).

==Sprint==
Sprint (or iteration) is the fundamental unit in which the work is divided; it is characterized by a fixed length of 2 weeks or 30 days and by a goal to achieve. At the beginning of each sprint Scrum team , Product Owner , Scrum Master and sometimes also stakeholders hold a meeting, called Sprint Planning meeting whose output is the Sprint Backlog where goals and requirements of the next Sprint are defined. Then other meetings inside development team will be held in order to define in more detail how achieving the common goals stated in the previous meeting.
==Scrum Meetings==
[[File:Scrum_meetings.png|350px|thumb|right|Scrum Meetings<ref name='James'></ref>]]
Meeting are a fundamental tool used during the whole Scrum process. Usually they are facilitated by the Scrum master who has no decision-making authority over them . There are different typologies of meetings according to the different phase of the process in which we are.
===Sprint Planning Meeting===
At the beginning of each Sprint, the Product Owner and team hold a Sprint Planning Meeting to define on which '''Product Backlog Items (PBIs)''' they will go to work during the next Sprint. "The Product Owner is responsible for declaring which items are the most important to the business. The team is responsible for selecting the amount of work they feel they can implement" (''M. James, 2010'')<ref name='James'></ref>.In this phase in perfect Lean perspective the team “pulls” work from the Product Backlog to the Sprint Backlog. At the end of the meeting the selected items are broken into a provisional list of Sprint task. The maximum time that can be used to do Planning meeting, known as '''timebox''', is of eight hours.

===Daily Scrum and Sprint Execution===
During the sprint every day members of the Scrum team hold a fifteen minutes meeting where they take stock of the situation. Usually they speak about what they did previous day, which impediments they faced and what they are going to do in the current day. To make these meetings shorter it is better that people are standing.
During sprint execution it is common to find out additional tasks necessary to achieve sprint goal; to keep the control over processes during sprint development it could be useful to maintain a current '''Sprint Task List''', a '''Sprint Burndown Chart''', and an '''Impediments List''': these are some artefacts that allow developer to understand where the project is located.

===Sprint Review Meeting===
At the end of every Sprint it is held a Review meeting where the scrum team has to explain to the Product Owner what they did during the previous sprint. Usually this meeting consists in a live demonstration of the working product increment after which Product Owner states which Items can be considered as done.
Items which are declared not done have to return to the Product Backlog to be ranked and reprioritized by the Product Owner with the help of the Scrum master. Last step of this meeting is to convert stakeholders’ feedback to a new Product Log, this task is consigned to both Product Owner and Scrum Master.
The Sprint Review Meeting is the appropriate meeting for external stakeholders (even end users) to attend.

===Sprint Retrospective Meeting===
During this meeting every member of the scrum team inspects his behaviour to identify some impediments that he faced during Sprint. There are mainly three kind of impediments in which developers can be involved:
*people who conduct performance evaluation are an obstacles to transparency of the team;
*human tendency of someone in the team to jump to conclusions and propose actions too quickly;
*geographical distribution of the team can be an impediments, team work better if they are delimited in a small place like a room.<ref name='James'></ref>

After identifying all these impediments Scrum master has the task to eliminate them.

===Backlog Refinement Meeting ===
Especially at the beginning of the project "most of the Product Backlog Items (PBIs) need refinement because they are too large and poorly understood" (''M. James, 2010'')<ref name='James'></ref>. In the Backlog Refinement Meeting, the team gave an estimation of the work left to complete Items in the Product Backlog and provides other technical information to help the Product Owner prioritize them.

==Artefacts==
[[File:Product_Backlog_2.png|350px|thumb|right|Product Backlog and Sprint Backlog<ref name='James'></ref>]]
===Product Backlog===

It is defined before the project beginning and then upgraded during the Backlog Refinement meeting ; it is made up by the whole group of items which have to be completed during the project in order to realize the final product. Every item is ranked and constantly reprioritized by the Product Owner. It is important that Product Backlog Is visible to the stakeholders.

===Product Backlog Item (PBI)===
An item specifies what has to be done but not how do it. Usually they are written in a User story to be understood also by stakeholders. Every items has a work load of 2-3 days and requires 2-3 people. It represents the basic unit of Product backlog.
[[File:Sprint_Backlog.png|200px|thumb|right|Sprint Backlog<ref name='James'></ref>]]
===Sprint backlog===

It is defined at the beginning of each sprint during the Sprint Planning meeting where committed items and the main task that have to be done during the sprint are identified. It has to be visible to Scrum team and it can be upgraded during the sprint execution with additional task necessary to achieve the final goal.

===Sprint task===
Every item is divided into several tasks, each of them requires one day or less of work. A sprint task specifies how to achieve what is required by PBI. If the task takes more than one day of work, remaining effort is re-estimated daily, typically in hours.

===Sprint Burndown Chart===
[[File:Sprint_burndown_chart.png|300px|thumb|right|Sprint Burndown Chart<ref name='James'></ref>]]
This tool is used to facilitate self-organization of the team. It indicates the total remaining team task hours within one Sprint. Usually chart shows a decreasing line but if there are some re-estimation it may be possible that line increase for then going down. As picture shows it has a time line in the x axis and the remaining hours of work within one Sprint in the y axis. The advantage of this tool is to show at a first sight at which point of the project you are and the work that is left to complete the Sprint. It is important that this tool is used only as help to Scrum team; in some situations it could become a constraint for developers, in this case Scrum Master has to remove this chart from the room.

=Limitations=
Scrum method was often used in the object-oriented software development. Actually this technique are applied not only on software but also on other products from different sectors like wheelchairs, semiconductors and mortgages.
Scrum has to be used in those projects where people cannot rely on the plan-driven approaches like Waterfall, because of unknown requirements and technology.
[[File:Graph.png|300px|thumb|right|Predictability of a Project<ref name='James'></ref>]]
Conversely if the projects is placed under precise and stable conditions it is better to use one of the traditional model which allow to have a fixed planning over the whole project. In this case Scrum method would involve in a waste of resources and money because he is working on a field that is not its responsibility.

Michael James in his “Scrum Reference card” explains with a simple graphics in which conditions Scrum should be used and which ones are not. James defines the predictability of the projects on the base of two features: knowledge of the requirements and knowledge of the level of technology required. A project which provides known requirements and a known level of technology should be carried out with a plan-driven model. It these conditions are not met it is better to use an empirical approach like Scrum.<ref name='James'></ref>

=References=
<references/>

Scrum Methodology in Agile Software Development

2015-09-28T19:27:02Z

S150821: /* Artefacts */

Today market is affected by uncertainly and sudden changes, in these conditions most of the models used in the 20th century to develop software are not still appropriate.[[Wikipedia:Waterfall model | Waterfall model]] , probably the most famous between them, is characterized by a stiff structure which can’t cope with the turbulent needs of actual market.
In recent years many innovations are been enhanced in software engineering with a particular focus on the flexibility of these methods in order to cope with the customers' and markets' needs; surely [[Wikipedia: Agile Software Development |Agile Software Development (ASD)]] is between them.

ASD embraces the principles of lean production by applying them in software development to avoid waste and increase responsiveness to change. It represents the solution to the unpredictability of the market where the capacity "to welcome change even late in development" (''K. Beck et all, 2001'')<ref name='Manifesto'></ref> to satisfy customers is required.
This article deals with Agile Software Development with a particular focus on one of its most used technique : '''Scrum Methodology'''.

=Scrum Methodology=
Scrum is an iterative method used to develop software, it can be placed inside the group of methods which are used in '''ASD'''. This word is taken from rugby and represents that phase of the match where an ordered formation of players, with arms interlocked and heads down, push forward against a similar group to gain possession of the ball<ref name='Cohen'></ref>. This method provides that "work is divided into small chunks to manage complexity and to get early feedback from customers and end users" (''S. Augustine, 2005'')<ref>S. Augustine,2005,Prentice Hall PTR,Managing Agile Projects</ref>; software development is carried out by small working team that allow rapid adjustment during the process and a quick delivery of the final product.

==Agile Software Development==
Some practitioners believed that traditional [[Wikipedia:Iterative model |Iterative model]] was not so responsive to changes that market required. They thought that to be Agile a process needs to accept change rather than stress predictability and that methods used to develop software has to respond to change as quickly as it arose rather than prevent changes.<ref name='Cohen'>D.Cohen,M.Lindval,P. Costa,Fraunhofer Center Maryland, Agile Software Development</ref>

It was in these circumstances that practitioners as Mary Poppendieck and Bob Charet started to take inspiration from Lean manufacturing principles and apply them to software development.
These are the main points ,according to Poppendieck, which make Lean Production so successful and that can be applied to software development:

*elimination of waste that does not add value to the customer such as diagram and models that do not add value to the final deliverable;
*minimize inventory such as requirements and design documents;
*maximize flow by using iterative development to reduce development time;
*pull from demand;
*empower workers that means “tell developer what needs to be done not how to do it";
*meet customer requirements – work closely with the customer, allowing them to change their minds
*do it right the first time – test early and refactor when necessary;
*abolish local optimization – flexibly manage scope;
*partner with suppliers – avoid adversarial relationships, work towards developing the best software;
*create a culture of continuous improvement – allow the process to improve, learn from mistakes and successes.<ref name='Cohen'></ref><ref>M. Poppendieck, T. Poppendieck, 2003, Addison Wesley, Lean Software Development: An Agile Toolkit[[http://www.poppendieck.com/]]</ref>

===Manifesto for the Agile Software development===
A few years before Poppoendieck’s publication on February 2001 main principles of Agile Software development were stated by a group of seventeen software developers which published “Manifesto for the Agile Software Development”.<ref name='Manifesto'>K. Beck et all., 2001, Manifesto for Agile Software Development[http://www.agilemanifesto.org/]</ref>

From reading these few words it is possible to identify what are the main innovations that ASD introduced in Software development:
[[File:Agilemanifesto.jpg|400px|thumb|right|Manifesto for the Agile Software development<ref name='Manifesto'></ref>]]

*'''“Individuals and interactions”''' : with these words founders want to remark the power of human being creativity, and his ability to collaborate with other similar. The stiffness of Waterfall model is instead represented by “processes and tools” where people has to follow only what the plan requires.
*'''“Working software “''' : there is a clear reference to the new way to develop software where at every iteration a working program is realised, differently from the earlier model in which a working program couldn’t be seen until the end of the project. This feature is put over the “comprehensive documentation” which characterizes especially Waterfall model.
*'''“Customer collaboration”''' : means that there must be a straight relationship between customer and developer in order to define time by time the projects requirements and evaluate every realise.
*'''“Responding to change over following a plan”''' : this sentence encloses the essence of Agile software Development that is to cope with turbulent markets by being flexible and by responding quickly to change, instead of being bound by planning. This concept is remarked by the founders in one of the twelve principles which follow the manifesto which says “Welcome changing requirements, even late in development […]”.

=Application=
[[File:Scrum_Framework.png|350px|thumb|right|Scrum Framework]]
There are two concepts that are at the basement of Scrum methodology: '''iterative development''' and '''team working'''. Developing in iterations allow Scrum team to adapt quickly to changing requirements, while working in close location and focusing on communication allow team to make decisions and act on them immediately rather than wait on correspondence.<ref name='Cohen'></ref>

Basically Scrum consists in a sequence of fixed-length iterations called [[Sprint:http://apppm.man.dtu.dk/index.php?title=Scrum_Methodology_in_Agile_Software_Development&action=submit#Sprint|Sprint]] managed by one or more '''cross-functional and self-organizing teams''' each composed by seven people that aim at a common goal and that usually work only on the software development. There are instead other two actors that manage all things that are in support of the development process: one is '''Product Owner''' who mainly handles customers contacts and the other is '''Scrum Master''' whose main task is to ensure that development team can work without obstacles.

Each sprint usually lasts from 2 to 4 weeks, in this period there are at least one meeting between the Product Owner and Development Team to define the main objectives; then there are short daily meetings held every morning to enhance communication and inform customers, developers, and managers on the status of the project, identify any problems encountered, and keep the entire team focused on a common goal.<ref name='Cohen'></ref>

==Main Actors in Scrum==
===Product Owner===
Product owner is the link between customers and development team, he ensures that deliverables are in line with customers’ expectation and that stakeholders’ interests are fulfilled. He has also the task to fill out customer-centric items (typically '''user stories'''), ranks and prioritizes them before adds them to '''Product Backlog'''.

Usually development teams have only one Product owner, but differently from the Scrum master, he only takes care of the business side and does not interfere with the scrum team about the technological issues. At the beginning of each Sprint the Product Owner holds a Sprint Planning Meeting to state on which Product Backlog Items Scrum team will go to work during the next Sprint. In this phase he defines what are the most important items for that business, in according to customer’s needs.

===Development Team===
Development team task is to provide Product Backlog Items (PBIs) at the end of every Sprint in according with customers’ requirements after negotiating commitments with the Product Owner.
Usually each team is composed by '''cross-functional members''' that allow an all-round software development; the main figures that there must be are a mix of software engineers, architects, programmers, analysts, QA experts, testers, and UI designers.

The size of the team is an important point, the group members' number influences capacity of people to communicate and work together: it is recommended that a scrum team is composed not more than nine people, usually seven.

Another important characteristic is the Self-organization of the group which facilitates members’ creativity and increases team cohesiveness: for this reason it is better to not change members of a team after they have worked together, especially if they had success in their project. After working together team members gain a mutual understanding that increases their capacity of team working, this synergy cannot be acquired if team are continuously changed.

A further point that characterized the good outcomes of a scrum team is location: people are most successful when located in the same room, particularly for the first few Sprints: this facilitates communication and information sharing.

====Team self-organization====
Team self-organization is a crucial point in the scrum methodology : with this concept it means that “it is told developer what needs to be done not how to do it”<ref name='Cohen'></ref>, they can autonomously choose the way to reach commitments.
As it is said previously during Sprint execution, team members develop an intrinsic interest in shared goals and learn to manage each other to achieve them, for this reason self-organizing teams can radically outperform larger than traditionally managed teams. It has to be specified that an optimal self-organization takes time: it may be possible that for the first few sprints developers perform worse than when they work in the traditional way.

Some requirements are necessary to gain a good team self-organization:
*members are committed to clear, short-term goals;
*members can gauge the group’s progress;
*members can observe each other’s contribution;
*members feel safe to give each other unvarnished feedback.<ref name='James'>M. James,2010,Scrum Reference Card, Michael James,[[http://scrumreferencecard.com/]]</ref>

Conversely there are some conditions that can hamper self-organization:
*geographical distribution: it is better if the whole team work in a room;
*boss/work dynamics: each member has to consider the others as peer to facilitate a fair communication between them;
*part-time team members;
*interruptions unrelated to Sprint goals.

===Scrum Master===
The scrum master worries that Scrum team can work without obstacles but he has no management authority over them. Essentially he has the aim to:
*create an environment to promote team self-organization;
*support team in the achievement of expected goals;
*ensure that events (e.g. daily Scrum meeting) take place in the right way;
*keep '''Scrum artefacts''' visible ('''Product Backlog''', '''Sprint Backlog''', '''Sprint burndown chart''' …).

==Sprint==
Sprint (or iteration) is the fundamental unit in which the work is divided; it is characterized by a fixed length of 2 weeks or 30 days and by a goal to achieve. At the beginning of each sprint Scrum team , Product Owner , Scrum Master and sometimes also stakeholders hold a meeting, called Sprint Planning meeting whose output is the Sprint Backlog where goals and requirements of the next Sprint are defined. Then other meetings inside development team will be held in order to define in more detail how achieving the common goals stated in the previous meeting.
==Scrum Meetings==
[[File:Scrum_meetings.png|350px|thumb|right|Scrum Meetings<ref name='James'></ref>]]
Meeting are a fundamental tool used during the whole Scrum process. Usually they are facilitated by the Scrum master who has no decision-making authority over them . There are different typologies of meetings according to the different phase of the process in which we are.
===Sprint Planning Meeting===
At the beginning of each Sprint, the Product Owner and team hold a Sprint Planning Meeting to define on which '''Product Backlog Items (PBIs)''' they will go to work during the next Sprint. "The Product Owner is responsible for declaring which items are the most important to the business. The team is responsible for selecting the amount of work they feel they can implement" (''M. James, 2010'')<ref name='James'></ref>.In this phase in perfect Lean perspective the team “pulls” work from the Product Backlog to the Sprint Backlog. At the end of the meeting the selected items are broken into a provisional list of Sprint task. The maximum time that can be used to do Planning meeting, known as '''timebox''', is of eight hours.

===Daily Scrum and Sprint Execution===
During the sprint every day members of the Scrum team hold a fifteen minutes meeting where they take stock of the situation. Usually they speak about what they did previous day, which impediments they faced and what they are going to do in the current day. To make these meetings shorter it is better that people are standing.
During sprint execution it is common to find out additional tasks necessary to achieve sprint goal; to keep the control over processes during sprint development it could be useful to maintain a current '''Sprint Task List''', a '''Sprint Burndown Chart''', and an '''Impediments List''': these are some artefacts that allow developer to understand where the project is located.

===Sprint Review Meeting===
At the end of every Sprint it is held a Review meeting where the scrum team has to explain to the Product Owner what they did during the previous sprint. Usually this meeting consists in a live demonstration of the working product increment after which Product Owner states which Items can be considered as done.
Items which are declared not done have to return to the Product Backlog to be ranked and reprioritized by the Product Owner with the help of the Scrum master. Last step of this meeting is to convert stakeholders’ feedback to a new Product Log, this task is consigned to both Product Owner and Scrum Master.
The Sprint Review Meeting is the appropriate meeting for external stakeholders (even end users) to attend.

===Sprint Retrospective Meeting===
During this meeting every member of the scrum team inspects his behaviour to identify some impediments that he faced during Sprint. There are mainly three kind of impediments in which developers can be involved:
*people who conduct performance evaluation are an obstacles to transparency of the team;
*human tendency of someone in the team to jump to conclusions and propose actions too quickly;
*geographical distribution of the team can be an impediments, team work better if they are delimited in a small place like a room.<ref name='James'></ref>

After identifying all these impediments Scrum master has the task to eliminate them.

===Backlog Refinement Meeting ===
Especially at the beginning of the project "most of the Product Backlog Items (PBIs) need refinement because they are too large and poorly understood" (''M. James, 2010'')<ref name='James'></ref>. In the Backlog Refinement Meeting, the team gave an estimation of the work left to complete Items in the Product Backlog and provides other technical information to help the Product Owner prioritize them.

==Artefacts==
[[File:Product_Backlog_3.png|200px|thumb|right|Product Backlog<ref name='James'></ref>]]
===Product Backlog===

It is defined before the project beginning and then upgraded during the Backlog Refinement meeting ; it is made up by the whole group of items which have to be completed during the project in order to realize the final product. Every item is ranked and constantly reprioritized by the Product Owner. It is important that Product Backlog Is visible to the stakeholders.

===Product Backlog Item (PBI)===
An item specifies what has to be done but not how do it. Usually they are written in a User story to be understood also by stakeholders. Every items has a work load of 2-3 days and requires 2-3 people. It represents the basic unit of Product backlog.
[[File:Sprint_Backlog.png|200px|thumb|right|Sprint Backlog<ref name='James'></ref>]]
===Sprint backlog===

It is defined at the beginning of each sprint during the Sprint Planning meeting where committed items and the main task that have to be done during the sprint are identified. It has to be visible to Scrum team and it can be upgraded during the sprint execution with additional task necessary to achieve the final goal.

===Sprint task===
Every item is divided into several tasks, each of them requires one day or less of work. A sprint task specifies how to achieve what is required by PBI. If the task takes more than one day of work, remaining effort is re-estimated daily, typically in hours.

===Sprint Burndown Chart===
[[File:Sprint_burndown_chart.png|300px|thumb|right|Sprint Burndown Chart<ref name='James'></ref>]]
This tool is used to facilitate self-organization of the team. It indicates the total remaining team task hours within one Sprint. Usually chart shows a decreasing line but if there are some re-estimation it may be possible that line increase for then going down. As picture shows it has a time line in the x axis and the remaining hours of work within one Sprint in the y axis. The advantage of this tool is to show at a first sight at which point of the project you are and the work that is left to complete the Sprint. It is important that this tool is used only as help to Scrum team; in some situations it could become a constraint for developers, in this case Scrum Master has to remove this chart from the room.

=Limitations=
Scrum method was often used in the object-oriented software development. Actually this technique are applied not only on software but also on other products from different sectors like wheelchairs, semiconductors and mortgages.
Scrum has to be used in those projects where people cannot rely on the plan-driven approaches like Waterfall, because of unknown requirements and technology.
[[File:Graph.png|300px|thumb|right|Predictability of a Project<ref name='James'></ref>]]
Conversely if the projects is placed under precise and stable conditions it is better to use one of the traditional model which allow to have a fixed planning over the whole project. In this case Scrum method would involve in a waste of resources and money because he is working on a field that is not its responsibility.

Michael James in his “Scrum Reference card” explains with a simple graphics in which conditions Scrum should be used and which ones are not. James defines the predictability of the projects on the base of two features: knowledge of the requirements and knowledge of the level of technology required. A project which provides known requirements and a known level of technology should be carried out with a plan-driven model. It these conditions are not met it is better to use an empirical approach like Scrum.<ref name='James'></ref>

=References=
<references/>

File:Burndown.png

2015-09-28T19:25:57Z

S150821:

File:Product Backlog 2.png

2015-09-28T19:25:17Z

S150821: S150821 uploaded a new version of "File:Product Backlog 2.png"

File:Product Backlog 2.png

2015-09-28T19:25:05Z

S150821:

File:Product Backlog 3.png

2015-09-28T19:24:35Z

S150821:

Scrum Methodology in Agile Software Development

2015-09-27T11:52:48Z

S150821: /* Team self-organization */

Today market is affected by uncertainly and sudden changes, in these conditions most of the models used in the 20th century to develop software are not still appropriate.[[Wikipedia:Waterfall model | Waterfall model]] , probably the most famous between them, is characterized by a stiff structure which can’t cope with the turbulent needs of actual market.
In recent years many innovations are been enhanced in software engineering with a particular focus on the flexibility of these methods in order to cope with the customers' and markets' needs; surely [[Wikipedia: Agile Software Development |Agile Software Development (ASD)]] is between them.

ASD embraces the principles of lean production by applying them in software development to avoid waste and increase responsiveness to change. It represents the solution to the unpredictability of the market where the capacity "to welcome change even late in development" (''K. Beck et all, 2001'')<ref name='Manifesto'></ref> to satisfy customers is required.
This article deals with Agile Software Development with a particular focus on one of its most used technique : '''Scrum Methodology'''.

=Scrum Methodology=
Scrum is an iterative method used to develop software, it can be placed inside the group of methods which are used in '''ASD'''. This word is taken from rugby and represents that phase of the match where an ordered formation of players, with arms interlocked and heads down, push forward against a similar group to gain possession of the ball<ref name='Cohen'></ref>. This method provides that "work is divided into small chunks to manage complexity and to get early feedback from customers and end users" (''S. Augustine, 2005'')<ref>S. Augustine,2005,Prentice Hall PTR,Managing Agile Projects</ref>; software development is carried out by small working team that allow rapid adjustment during the process and a quick delivery of the final product.

==Agile Software Development==
Some practitioners believed that traditional [[Wikipedia:Iterative model |Iterative model]] was not so responsive to changes that market required. They thought that to be Agile a process needs to accept change rather than stress predictability and that methods used to develop software has to respond to change as quickly as it arose rather than prevent changes.<ref name='Cohen'>D.Cohen,M.Lindval,P. Costa,Fraunhofer Center Maryland, Agile Software Development</ref>

It was in these circumstances that practitioners as Mary Poppendieck and Bob Charet started to take inspiration from Lean manufacturing principles and apply them to software development.
These are the main points ,according to Poppendieck, which make Lean Production so successful and that can be applied to software development:

*elimination of waste that does not add value to the customer such as diagram and models that do not add value to the final deliverable;
*minimize inventory such as requirements and design documents;
*maximize flow by using iterative development to reduce development time;
*pull from demand;
*empower workers that means “tell developer what needs to be done not how to do it";
*meet customer requirements – work closely with the customer, allowing them to change their minds
*do it right the first time – test early and refactor when necessary;
*abolish local optimization – flexibly manage scope;
*partner with suppliers – avoid adversarial relationships, work towards developing the best software;
*create a culture of continuous improvement – allow the process to improve, learn from mistakes and successes.<ref name='Cohen'></ref><ref>M. Poppendieck, T. Poppendieck, 2003, Addison Wesley, Lean Software Development: An Agile Toolkit[[http://www.poppendieck.com/]]</ref>

===Manifesto for the Agile Software development===
A few years before Poppoendieck’s publication on February 2001 main principles of Agile Software development were stated by a group of seventeen software developers which published “Manifesto for the Agile Software Development”.<ref name='Manifesto'>K. Beck et all., 2001, Manifesto for Agile Software Development[http://www.agilemanifesto.org/]</ref>

From reading these few words it is possible to identify what are the main innovations that ASD introduced in Software development:
[[File:Agilemanifesto.jpg|400px|thumb|right|Manifesto for the Agile Software development<ref name='Manifesto'></ref>]]

*'''“Individuals and interactions”''' : with these words founders want to remark the power of human being creativity, and his ability to collaborate with other similar. The stiffness of Waterfall model is instead represented by “processes and tools” where people has to follow only what the plan requires.
*'''“Working software “''' : there is a clear reference to the new way to develop software where at every iteration a working program is realised, differently from the earlier model in which a working program couldn’t be seen until the end of the project. This feature is put over the “comprehensive documentation” which characterizes especially Waterfall model.
*'''“Customer collaboration”''' : means that there must be a straight relationship between customer and developer in order to define time by time the projects requirements and evaluate every realise.
*'''“Responding to change over following a plan”''' : this sentence encloses the essence of Agile software Development that is to cope with turbulent markets by being flexible and by responding quickly to change, instead of being bound by planning. This concept is remarked by the founders in one of the twelve principles which follow the manifesto which says “Welcome changing requirements, even late in development […]”.

=Application=
[[File:Scrum_Framework.png|350px|thumb|right|Scrum Framework]]
There are two concepts that are at the basement of Scrum methodology: '''iterative development''' and '''team working'''. Developing in iterations allow Scrum team to adapt quickly to changing requirements, while working in close location and focusing on communication allow team to make decisions and act on them immediately rather than wait on correspondence.<ref name='Cohen'></ref>

Basically Scrum consists in a sequence of fixed-length iterations called [[Sprint:http://apppm.man.dtu.dk/index.php?title=Scrum_Methodology_in_Agile_Software_Development&action=submit#Sprint|Sprint]] managed by one or more '''cross-functional and self-organizing teams''' each composed by seven people that aim at a common goal and that usually work only on the software development. There are instead other two actors that manage all things that are in support of the development process: one is '''Product Owner''' who mainly handles customers contacts and the other is '''Scrum Master''' whose main task is to ensure that development team can work without obstacles.

Each sprint usually lasts from 2 to 4 weeks, in this period there are at least one meeting between the Product Owner and Development Team to define the main objectives; then there are short daily meetings held every morning to enhance communication and inform customers, developers, and managers on the status of the project, identify any problems encountered, and keep the entire team focused on a common goal.<ref name='Cohen'></ref>

==Main Actors in Scrum==
===Product Owner===
Product owner is the link between customers and development team, he ensures that deliverables are in line with customers’ expectation and that stakeholders’ interests are fulfilled. He has also the task to fill out customer-centric items (typically '''user stories'''), ranks and prioritizes them before adds them to '''Product Backlog'''.

Usually development teams have only one Product owner, but differently from the Scrum master, he only takes care of the business side and does not interfere with the scrum team about the technological issues. At the beginning of each Sprint the Product Owner holds a Sprint Planning Meeting to state on which Product Backlog Items Scrum team will go to work during the next Sprint. In this phase he defines what are the most important items for that business, in according to customer’s needs.

===Development Team===
Development team task is to provide Product Backlog Items (PBIs) at the end of every Sprint in according with customers’ requirements after negotiating commitments with the Product Owner.
Usually each team is composed by '''cross-functional members''' that allow an all-round software development; the main figures that there must be are a mix of software engineers, architects, programmers, analysts, QA experts, testers, and UI designers.

The size of the team is an important point, the group members' number influences capacity of people to communicate and work together: it is recommended that a scrum team is composed not more than nine people, usually seven.

Another important characteristic is the Self-organization of the group which facilitates members’ creativity and increases team cohesiveness: for this reason it is better to not change members of a team after they have worked together, especially if they had success in their project. After working together team members gain a mutual understanding that increases their capacity of team working, this synergy cannot be acquired if team are continuously changed.

A further point that characterized the good outcomes of a scrum team is location: people are most successful when located in the same room, particularly for the first few Sprints: this facilitates communication and information sharing.

====Team self-organization====
Team self-organization is a crucial point in the scrum methodology : with this concept it means that “it is told developer what needs to be done not how to do it”<ref name='Cohen'></ref>, they can autonomously choose the way to reach commitments.
As it is said previously during Sprint execution, team members develop an intrinsic interest in shared goals and learn to manage each other to achieve them, for this reason self-organizing teams can radically outperform larger than traditionally managed teams. It has to be specified that an optimal self-organization takes time: it may be possible that for the first few sprints developers perform worse than when they work in the traditional way.

Some requirements are necessary to gain a good team self-organization:
*members are committed to clear, short-term goals;
*members can gauge the group’s progress;
*members can observe each other’s contribution;
*members feel safe to give each other unvarnished feedback.<ref name='James'>M. James,2010,Scrum Reference Card, Michael James,[[http://scrumreferencecard.com/]]</ref>

Conversely there are some conditions that can hamper self-organization:
*geographical distribution: it is better if the whole team work in a room;
*boss/work dynamics: each member has to consider the others as peer to facilitate a fair communication between them;
*part-time team members;
*interruptions unrelated to Sprint goals.

===Scrum Master===
The scrum master worries that Scrum team can work without obstacles but he has no management authority over them. Essentially he has the aim to:
*create an environment to promote team self-organization;
*support team in the achievement of expected goals;
*ensure that events (e.g. daily Scrum meeting) take place in the right way;
*keep '''Scrum artefacts''' visible ('''Product Backlog''', '''Sprint Backlog''', '''Sprint burndown chart''' …).

==Sprint==
Sprint (or iteration) is the fundamental unit in which the work is divided; it is characterized by a fixed length of 2 weeks or 30 days and by a goal to achieve. At the beginning of each sprint Scrum team , Product Owner , Scrum Master and sometimes also stakeholders hold a meeting, called Sprint Planning meeting whose output is the Sprint Backlog where goals and requirements of the next Sprint are defined. Then other meetings inside development team will be held in order to define in more detail how achieving the common goals stated in the previous meeting.
==Scrum Meetings==
[[File:Scrum_meetings.png|350px|thumb|right|Scrum Meetings<ref name='James'></ref>]]
Meeting are a fundamental tool used during the whole Scrum process. Usually they are facilitated by the Scrum master who has no decision-making authority over them . There are different typologies of meetings according to the different phase of the process in which we are.
===Sprint Planning Meeting===
At the beginning of each Sprint, the Product Owner and team hold a Sprint Planning Meeting to define on which '''Product Backlog Items (PBIs)''' they will go to work during the next Sprint. "The Product Owner is responsible for declaring which items are the most important to the business. The team is responsible for selecting the amount of work they feel they can implement" (''M. James, 2010'')<ref name='James'></ref>.In this phase in perfect Lean perspective the team “pulls” work from the Product Backlog to the Sprint Backlog. At the end of the meeting the selected items are broken into a provisional list of Sprint task. The maximum time that can be used to do Planning meeting, known as '''timebox''', is of eight hours.

===Daily Scrum and Sprint Execution===
During the sprint every day members of the Scrum team hold a fifteen minutes meeting where they take stock of the situation. Usually they speak about what they did previous day, which impediments they faced and what they are going to do in the current day. To make these meetings shorter it is better that people are standing.
During sprint execution it is common to find out additional tasks necessary to achieve sprint goal; to keep the control over processes during sprint development it could be useful to maintain a current '''Sprint Task List''', a '''Sprint Burndown Chart''', and an '''Impediments List''': these are some artefacts that allow developer to understand where the project is located.

===Sprint Review Meeting===
At the end of every Sprint it is held a Review meeting where the scrum team has to explain to the Product Owner what they did during the previous sprint. Usually this meeting consists in a live demonstration of the working product increment after which Product Owner states which Items can be considered as done.
Items which are declared not done have to return to the Product Backlog to be ranked and reprioritized by the Product Owner with the help of the Scrum master. Last step of this meeting is to convert stakeholders’ feedback to a new Product Log, this task is consigned to both Product Owner and Scrum Master.
The Sprint Review Meeting is the appropriate meeting for external stakeholders (even end users) to attend.

===Sprint Retrospective Meeting===
During this meeting every member of the scrum team inspects his behaviour to identify some impediments that he faced during Sprint. There are mainly three kind of impediments in which developers can be involved:
*people who conduct performance evaluation are an obstacles to transparency of the team;
*human tendency of someone in the team to jump to conclusions and propose actions too quickly;
*geographical distribution of the team can be an impediments, team work better if they are delimited in a small place like a room.<ref name='James'></ref>

After identifying all these impediments Scrum master has the task to eliminate them.

===Backlog Refinement Meeting ===
Especially at the beginning of the project "most of the Product Backlog Items (PBIs) need refinement because they are too large and poorly understood" (''M. James, 2010'')<ref name='James'></ref>. In the Backlog Refinement Meeting, the team gave an estimation of the work left to complete Items in the Product Backlog and provides other technical information to help the Product Owner prioritize them.

==Artefacts==
[[File:Product_Backlog.png|200px|thumb|right|Product Backlog<ref name='James'></ref>]]
===Product Backlog===

It is defined before the project beginning and then upgraded during the Backlog Refinement meeting ; it is made up by the whole group of items which have to be completed during the project in order to realize the final product. Every item is ranked and constantly reprioritized by the Product Owner. It is important that Product Backlog Is visible to the stakeholders.

===Product Backlog Item (PBI)===
An item specifies what has to be done but not how do it. Usually they are written in a User story to be understood also by stakeholders. Every items has a work load of 2-3 days and requires 2-3 people. It represents the basic unit of Product backlog.
[[File:Sprint_Backlog.png|200px|thumb|right|Sprint Backlog<ref name='James'></ref>]]
===Sprint backlog===

It is defined at the beginning of each sprint during the Sprint Planning meeting where committed items and the main task that have to be done during the sprint are identified. It has to be visible to Scrum team and it can be upgraded during the sprint execution with additional task necessary to achieve the final goal.

===Sprint task===
Every item is divided into several tasks, each of them requires one day or less of work. A sprint task specifies how to achieve what is required by PBI. If the task takes more than one day of work, remaining effort is re-estimated daily, typically in hours.

===Sprint Burndown Chart===
[[File:Sprint_burndown_chart.png|300px|thumb|right|Sprint Burndown Chart<ref name='James'></ref>]]
This tool is used to facilitate self-organization of the team. It indicates the total remaining team task hours within one Sprint. Usually chart shows a decreasing line but if there are some re-estimation it may be possible that line increase for then going down. As picture shows it has a time line in the x axis and the remaining hours of work within one Sprint in the y axis. The advantage of this tool is to show at a first sight at which point of the project you are and the work that is left to complete the Sprint. It is important that this tool is used only as help to Scrum team; in some situations it could become a constraint for developers, in this case Scrum Master has to remove this chart from the room.

=Limitations=
Scrum method was often used in the object-oriented software development. Actually this technique are applied not only on software but also on other products from different sectors like wheelchairs, semiconductors and mortgages.
Scrum has to be used in those projects where people cannot rely on the plan-driven approaches like Waterfall, because of unknown requirements and technology.
[[File:Graph.png|300px|thumb|right|Predictability of a Project<ref name='James'></ref>]]
Conversely if the projects is placed under precise and stable conditions it is better to use one of the traditional model which allow to have a fixed planning over the whole project. In this case Scrum method would involve in a waste of resources and money because he is working on a field that is not its responsibility.

Michael James in his “Scrum Reference card” explains with a simple graphics in which conditions Scrum should be used and which ones are not. James defines the predictability of the projects on the base of two features: knowledge of the requirements and knowledge of the level of technology required. A project which provides known requirements and a known level of technology should be carried out with a plan-driven model. It these conditions are not met it is better to use an empirical approach like Scrum.<ref name='James'></ref>

=References=
<references/>

Scrum Methodology in Agile Software Development

2015-09-27T11:50:43Z

S150821: /* Team self-organization */

Today market is affected by uncertainly and sudden changes, in these conditions most of the models used in the 20th century to develop software are not still appropriate.[[Wikipedia:Waterfall model | Waterfall model]] , probably the most famous between them, is characterized by a stiff structure which can’t cope with the turbulent needs of actual market.
In recent years many innovations are been enhanced in software engineering with a particular focus on the flexibility of these methods in order to cope with the customers' and markets' needs; surely [[Wikipedia: Agile Software Development |Agile Software Development (ASD)]] is between them.

ASD embraces the principles of lean production by applying them in software development to avoid waste and increase responsiveness to change. It represents the solution to the unpredictability of the market where the capacity "to welcome change even late in development" (''K. Beck et all, 2001'')<ref name='Manifesto'></ref> to satisfy customers is required.
This article deals with Agile Software Development with a particular focus on one of its most used technique : '''Scrum Methodology'''.

=Scrum Methodology=
Scrum is an iterative method used to develop software, it can be placed inside the group of methods which are used in '''ASD'''. This word is taken from rugby and represents that phase of the match where an ordered formation of players, with arms interlocked and heads down, push forward against a similar group to gain possession of the ball<ref name='Cohen'></ref>. This method provides that "work is divided into small chunks to manage complexity and to get early feedback from customers and end users" (''S. Augustine, 2005'')<ref>S. Augustine,2005,Prentice Hall PTR,Managing Agile Projects</ref>; software development is carried out by small working team that allow rapid adjustment during the process and a quick delivery of the final product.

==Agile Software Development==
Some practitioners believed that traditional [[Wikipedia:Iterative model |Iterative model]] was not so responsive to changes that market required. They thought that to be Agile a process needs to accept change rather than stress predictability and that methods used to develop software has to respond to change as quickly as it arose rather than prevent changes.<ref name='Cohen'>D.Cohen,M.Lindval,P. Costa,Fraunhofer Center Maryland, Agile Software Development</ref>

It was in these circumstances that practitioners as Mary Poppendieck and Bob Charet started to take inspiration from Lean manufacturing principles and apply them to software development.
These are the main points ,according to Poppendieck, which make Lean Production so successful and that can be applied to software development:

*elimination of waste that does not add value to the customer such as diagram and models that do not add value to the final deliverable;
*minimize inventory such as requirements and design documents;
*maximize flow by using iterative development to reduce development time;
*pull from demand;
*empower workers that means “tell developer what needs to be done not how to do it";
*meet customer requirements – work closely with the customer, allowing them to change their minds
*do it right the first time – test early and refactor when necessary;
*abolish local optimization – flexibly manage scope;
*partner with suppliers – avoid adversarial relationships, work towards developing the best software;
*create a culture of continuous improvement – allow the process to improve, learn from mistakes and successes.<ref name='Cohen'></ref><ref>M. Poppendieck, T. Poppendieck, 2003, Addison Wesley, Lean Software Development: An Agile Toolkit[[http://www.poppendieck.com/]]</ref>

===Manifesto for the Agile Software development===
A few years before Poppoendieck’s publication on February 2001 main principles of Agile Software development were stated by a group of seventeen software developers which published “Manifesto for the Agile Software Development”.<ref name='Manifesto'>K. Beck et all., 2001, Manifesto for Agile Software Development[http://www.agilemanifesto.org/]</ref>

From reading these few words it is possible to identify what are the main innovations that ASD introduced in Software development:
[[File:Agilemanifesto.jpg|400px|thumb|right|Manifesto for the Agile Software development<ref name='Manifesto'></ref>]]

*'''“Individuals and interactions”''' : with these words founders want to remark the power of human being creativity, and his ability to collaborate with other similar. The stiffness of Waterfall model is instead represented by “processes and tools” where people has to follow only what the plan requires.
*'''“Working software “''' : there is a clear reference to the new way to develop software where at every iteration a working program is realised, differently from the earlier model in which a working program couldn’t be seen until the end of the project. This feature is put over the “comprehensive documentation” which characterizes especially Waterfall model.
*'''“Customer collaboration”''' : means that there must be a straight relationship between customer and developer in order to define time by time the projects requirements and evaluate every realise.
*'''“Responding to change over following a plan”''' : this sentence encloses the essence of Agile software Development that is to cope with turbulent markets by being flexible and by responding quickly to change, instead of being bound by planning. This concept is remarked by the founders in one of the twelve principles which follow the manifesto which says “Welcome changing requirements, even late in development […]”.

=Application=
[[File:Scrum_Framework.png|350px|thumb|right|Scrum Framework]]
There are two concepts that are at the basement of Scrum methodology: '''iterative development''' and '''team working'''. Developing in iterations allow Scrum team to adapt quickly to changing requirements, while working in close location and focusing on communication allow team to make decisions and act on them immediately rather than wait on correspondence.<ref name='Cohen'></ref>

Basically Scrum consists in a sequence of fixed-length iterations called [[Sprint:http://apppm.man.dtu.dk/index.php?title=Scrum_Methodology_in_Agile_Software_Development&action=submit#Sprint|Sprint]] managed by one or more '''cross-functional and self-organizing teams''' each composed by seven people that aim at a common goal and that usually work only on the software development. There are instead other two actors that manage all things that are in support of the development process: one is '''Product Owner''' who mainly handles customers contacts and the other is '''Scrum Master''' whose main task is to ensure that development team can work without obstacles.

Each sprint usually lasts from 2 to 4 weeks, in this period there are at least one meeting between the Product Owner and Development Team to define the main objectives; then there are short daily meetings held every morning to enhance communication and inform customers, developers, and managers on the status of the project, identify any problems encountered, and keep the entire team focused on a common goal.<ref name='Cohen'></ref>

==Main Actors in Scrum==
===Product Owner===
Product owner is the link between customers and development team, he ensures that deliverables are in line with customers’ expectation and that stakeholders’ interests are fulfilled. He has also the task to fill out customer-centric items (typically '''user stories'''), ranks and prioritizes them before adds them to '''Product Backlog'''.

Usually development teams have only one Product owner, but differently from the Scrum master, he only takes care of the business side and does not interfere with the scrum team about the technological issues. At the beginning of each Sprint the Product Owner holds a Sprint Planning Meeting to state on which Product Backlog Items Scrum team will go to work during the next Sprint. In this phase he defines what are the most important items for that business, in according to customer’s needs.

===Development Team===
Development team task is to provide Product Backlog Items (PBIs) at the end of every Sprint in according with customers’ requirements after negotiating commitments with the Product Owner.
Usually each team is composed by '''cross-functional members''' that allow an all-round software development; the main figures that there must be are a mix of software engineers, architects, programmers, analysts, QA experts, testers, and UI designers.

The size of the team is an important point, the group members' number influences capacity of people to communicate and work together: it is recommended that a scrum team is composed not more than nine people, usually seven.

Another important characteristic is the Self-organization of the group which facilitates members’ creativity and increases team cohesiveness: for this reason it is better to not change members of a team after they have worked together, especially if they had success in their project. After working together team members gain a mutual understanding that increases their capacity of team working, this synergy cannot be acquired if team are continuously changed.

A further point that characterized the good outcomes of a scrum team is location: people are most successful when located in the same room, particularly for the first few Sprints: this facilitates communication and information sharing.

====Team self-organization====
Team self-organization is a crucial point in the scrum methodology : with this concept it means that “it is told developer what needs to be done not how to do it”, they can autonomously choose the way to reach commitments.
As it is said previously during Sprint execution, team members develop an intrinsic interest in shared goals and learn to manage each other to achieve them, for this reason self-organizing teams can radically outperform larger than traditionally managed teams. It has to be specified that an optimal self-organization takes time: it may be possible that for the first few sprints developers perform worse than when they work in the traditional way.

Some requirements are necessary to gain a good team self-organization:
*members are committed to clear, short-term goals;
*members can gauge the group’s progress;
*members can observe each other’s contribution;
*members feel safe to give each other unvarnished feedback.<ref name='James'>M. James,2010,Scrum Reference Card, Michael James,[[http://scrumreferencecard.com/]]</ref>

Conversely there are some conditions that can hamper self-organization:
*geographical distribution: it is better if the whole team work in a room;
*boss/work dynamics: each member has to consider the others as peer to facilitate a fair communication between them;
*part-time team members;
*interruptions unrelated to Sprint goals.

===Scrum Master===
The scrum master worries that Scrum team can work without obstacles but he has no management authority over them. Essentially he has the aim to:
*create an environment to promote team self-organization;
*support team in the achievement of expected goals;
*ensure that events (e.g. daily Scrum meeting) take place in the right way;
*keep '''Scrum artefacts''' visible ('''Product Backlog''', '''Sprint Backlog''', '''Sprint burndown chart''' …).

==Sprint==
Sprint (or iteration) is the fundamental unit in which the work is divided; it is characterized by a fixed length of 2 weeks or 30 days and by a goal to achieve. At the beginning of each sprint Scrum team , Product Owner , Scrum Master and sometimes also stakeholders hold a meeting, called Sprint Planning meeting whose output is the Sprint Backlog where goals and requirements of the next Sprint are defined. Then other meetings inside development team will be held in order to define in more detail how achieving the common goals stated in the previous meeting.
==Scrum Meetings==
[[File:Scrum_meetings.png|350px|thumb|right|Scrum Meetings<ref name='James'></ref>]]
Meeting are a fundamental tool used during the whole Scrum process. Usually they are facilitated by the Scrum master who has no decision-making authority over them . There are different typologies of meetings according to the different phase of the process in which we are.
===Sprint Planning Meeting===
At the beginning of each Sprint, the Product Owner and team hold a Sprint Planning Meeting to define on which '''Product Backlog Items (PBIs)''' they will go to work during the next Sprint. "The Product Owner is responsible for declaring which items are the most important to the business. The team is responsible for selecting the amount of work they feel they can implement" (''M. James, 2010'')<ref name='James'></ref>.In this phase in perfect Lean perspective the team “pulls” work from the Product Backlog to the Sprint Backlog. At the end of the meeting the selected items are broken into a provisional list of Sprint task. The maximum time that can be used to do Planning meeting, known as '''timebox''', is of eight hours.

===Daily Scrum and Sprint Execution===
During the sprint every day members of the Scrum team hold a fifteen minutes meeting where they take stock of the situation. Usually they speak about what they did previous day, which impediments they faced and what they are going to do in the current day. To make these meetings shorter it is better that people are standing.
During sprint execution it is common to find out additional tasks necessary to achieve sprint goal; to keep the control over processes during sprint development it could be useful to maintain a current '''Sprint Task List''', a '''Sprint Burndown Chart''', and an '''Impediments List''': these are some artefacts that allow developer to understand where the project is located.

===Sprint Review Meeting===
At the end of every Sprint it is held a Review meeting where the scrum team has to explain to the Product Owner what they did during the previous sprint. Usually this meeting consists in a live demonstration of the working product increment after which Product Owner states which Items can be considered as done.
Items which are declared not done have to return to the Product Backlog to be ranked and reprioritized by the Product Owner with the help of the Scrum master. Last step of this meeting is to convert stakeholders’ feedback to a new Product Log, this task is consigned to both Product Owner and Scrum Master.
The Sprint Review Meeting is the appropriate meeting for external stakeholders (even end users) to attend.

===Sprint Retrospective Meeting===
During this meeting every member of the scrum team inspects his behaviour to identify some impediments that he faced during Sprint. There are mainly three kind of impediments in which developers can be involved:
*people who conduct performance evaluation are an obstacles to transparency of the team;
*human tendency of someone in the team to jump to conclusions and propose actions too quickly;
*geographical distribution of the team can be an impediments, team work better if they are delimited in a small place like a room.<ref name='James'></ref>

After identifying all these impediments Scrum master has the task to eliminate them.

===Backlog Refinement Meeting ===
Especially at the beginning of the project "most of the Product Backlog Items (PBIs) need refinement because they are too large and poorly understood" (''M. James, 2010'')<ref name='James'></ref>. In the Backlog Refinement Meeting, the team gave an estimation of the work left to complete Items in the Product Backlog and provides other technical information to help the Product Owner prioritize them.

==Artefacts==
[[File:Product_Backlog.png|200px|thumb|right|Product Backlog<ref name='James'></ref>]]
===Product Backlog===

It is defined before the project beginning and then upgraded during the Backlog Refinement meeting ; it is made up by the whole group of items which have to be completed during the project in order to realize the final product. Every item is ranked and constantly reprioritized by the Product Owner. It is important that Product Backlog Is visible to the stakeholders.

===Product Backlog Item (PBI)===
An item specifies what has to be done but not how do it. Usually they are written in a User story to be understood also by stakeholders. Every items has a work load of 2-3 days and requires 2-3 people. It represents the basic unit of Product backlog.
[[File:Sprint_Backlog.png|200px|thumb|right|Sprint Backlog<ref name='James'></ref>]]
===Sprint backlog===

It is defined at the beginning of each sprint during the Sprint Planning meeting where committed items and the main task that have to be done during the sprint are identified. It has to be visible to Scrum team and it can be upgraded during the sprint execution with additional task necessary to achieve the final goal.

===Sprint task===
Every item is divided into several tasks, each of them requires one day or less of work. A sprint task specifies how to achieve what is required by PBI. If the task takes more than one day of work, remaining effort is re-estimated daily, typically in hours.

===Sprint Burndown Chart===
[[File:Sprint_burndown_chart.png|300px|thumb|right|Sprint Burndown Chart<ref name='James'></ref>]]
This tool is used to facilitate self-organization of the team. It indicates the total remaining team task hours within one Sprint. Usually chart shows a decreasing line but if there are some re-estimation it may be possible that line increase for then going down. As picture shows it has a time line in the x axis and the remaining hours of work within one Sprint in the y axis. The advantage of this tool is to show at a first sight at which point of the project you are and the work that is left to complete the Sprint. It is important that this tool is used only as help to Scrum team; in some situations it could become a constraint for developers, in this case Scrum Master has to remove this chart from the room.

=Limitations=
Scrum method was often used in the object-oriented software development. Actually this technique are applied not only on software but also on other products from different sectors like wheelchairs, semiconductors and mortgages.
Scrum has to be used in those projects where people cannot rely on the plan-driven approaches like Waterfall, because of unknown requirements and technology.
[[File:Graph.png|300px|thumb|right|Predictability of a Project<ref name='James'></ref>]]
Conversely if the projects is placed under precise and stable conditions it is better to use one of the traditional model which allow to have a fixed planning over the whole project. In this case Scrum method would involve in a waste of resources and money because he is working on a field that is not its responsibility.

Michael James in his “Scrum Reference card” explains with a simple graphics in which conditions Scrum should be used and which ones are not. James defines the predictability of the projects on the base of two features: knowledge of the requirements and knowledge of the level of technology required. A project which provides known requirements and a known level of technology should be carried out with a plan-driven model. It these conditions are not met it is better to use an empirical approach like Scrum.<ref name='James'></ref>

=References=
<references/>

Scrum Methodology in Agile Software Development

2015-09-27T11:33:21Z

S150821: /* Application */

Today market is affected by uncertainly and sudden changes, in these conditions most of the models used in the 20th century to develop software are not still appropriate.[[Wikipedia:Waterfall model | Waterfall model]] , probably the most famous between them, is characterized by a stiff structure which can’t cope with the turbulent needs of actual market.
In recent years many innovations are been enhanced in software engineering with a particular focus on the flexibility of these methods in order to cope with the customers' and markets' needs; surely [[Wikipedia: Agile Software Development |Agile Software Development (ASD)]] is between them.

ASD embraces the principles of lean production by applying them in software development to avoid waste and increase responsiveness to change. It represents the solution to the unpredictability of the market where the capacity "to welcome change even late in development" (''K. Beck et all, 2001'')<ref name='Manifesto'></ref> to satisfy customers is required.
This article deals with Agile Software Development with a particular focus on one of its most used technique : '''Scrum Methodology'''.

=Scrum Methodology=
Scrum is an iterative method used to develop software, it can be placed inside the group of methods which are used in '''ASD'''. This word is taken from rugby and represents that phase of the match where an ordered formation of players, with arms interlocked and heads down, push forward against a similar group to gain possession of the ball<ref name='Cohen'></ref>. This method provides that "work is divided into small chunks to manage complexity and to get early feedback from customers and end users" (''S. Augustine, 2005'')<ref>S. Augustine,2005,Prentice Hall PTR,Managing Agile Projects</ref>; software development is carried out by small working team that allow rapid adjustment during the process and a quick delivery of the final product.

==Agile Software Development==
Some practitioners believed that traditional [[Wikipedia:Iterative model |Iterative model]] was not so responsive to changes that market required. They thought that to be Agile a process needs to accept change rather than stress predictability and that methods used to develop software has to respond to change as quickly as it arose rather than prevent changes.<ref name='Cohen'>D.Cohen,M.Lindval,P. Costa,Fraunhofer Center Maryland, Agile Software Development</ref>

It was in these circumstances that practitioners as Mary Poppendieck and Bob Charet started to take inspiration from Lean manufacturing principles and apply them to software development.
These are the main points ,according to Poppendieck, which make Lean Production so successful and that can be applied to software development:

*elimination of waste that does not add value to the customer such as diagram and models that do not add value to the final deliverable;
*minimize inventory such as requirements and design documents;
*maximize flow by using iterative development to reduce development time;
*pull from demand;
*empower workers that means “tell developer what needs to be done not how to do it";
*meet customer requirements – work closely with the customer, allowing them to change their minds
*do it right the first time – test early and refactor when necessary;
*abolish local optimization – flexibly manage scope;
*partner with suppliers – avoid adversarial relationships, work towards developing the best software;
*create a culture of continuous improvement – allow the process to improve, learn from mistakes and successes.<ref name='Cohen'></ref><ref>M. Poppendieck, T. Poppendieck, 2003, Addison Wesley, Lean Software Development: An Agile Toolkit[[http://www.poppendieck.com/]]</ref>

===Manifesto for the Agile Software development===
A few years before Poppoendieck’s publication on February 2001 main principles of Agile Software development were stated by a group of seventeen software developers which published “Manifesto for the Agile Software Development”.<ref name='Manifesto'>K. Beck et all., 2001, Manifesto for Agile Software Development[http://www.agilemanifesto.org/]</ref>

From reading these few words it is possible to identify what are the main innovations that ASD introduced in Software development:
[[File:Agilemanifesto.jpg|400px|thumb|right|Manifesto for the Agile Software development<ref name='Manifesto'></ref>]]

*'''“Individuals and interactions”''' : with these words founders want to remark the power of human being creativity, and his ability to collaborate with other similar. The stiffness of Waterfall model is instead represented by “processes and tools” where people has to follow only what the plan requires.
*'''“Working software “''' : there is a clear reference to the new way to develop software where at every iteration a working program is realised, differently from the earlier model in which a working program couldn’t be seen until the end of the project. This feature is put over the “comprehensive documentation” which characterizes especially Waterfall model.
*'''“Customer collaboration”''' : means that there must be a straight relationship between customer and developer in order to define time by time the projects requirements and evaluate every realise.
*'''“Responding to change over following a plan”''' : this sentence encloses the essence of Agile software Development that is to cope with turbulent markets by being flexible and by responding quickly to change, instead of being bound by planning. This concept is remarked by the founders in one of the twelve principles which follow the manifesto which says “Welcome changing requirements, even late in development […]”.

=Application=
[[File:Scrum_Framework.png|350px|thumb|right|Scrum Framework]]
There are two concepts that are at the basement of Scrum methodology: '''iterative development''' and '''team working'''. Developing in iterations allow Scrum team to adapt quickly to changing requirements, while working in close location and focusing on communication allow team to make decisions and act on them immediately rather than wait on correspondence.<ref name='Cohen'></ref>

Basically Scrum consists in a sequence of fixed-length iterations called [[Sprint:http://apppm.man.dtu.dk/index.php?title=Scrum_Methodology_in_Agile_Software_Development&action=submit#Sprint|Sprint]] managed by one or more '''cross-functional and self-organizing teams''' each composed by seven people that aim at a common goal and that usually work only on the software development. There are instead other two actors that manage all things that are in support of the development process: one is '''Product Owner''' who mainly handles customers contacts and the other is '''Scrum Master''' whose main task is to ensure that development team can work without obstacles.

Each sprint usually lasts from 2 to 4 weeks, in this period there are at least one meeting between the Product Owner and Development Team to define the main objectives; then there are short daily meetings held every morning to enhance communication and inform customers, developers, and managers on the status of the project, identify any problems encountered, and keep the entire team focused on a common goal.<ref name='Cohen'></ref>

==Main Actors in Scrum==
===Product Owner===
Product owner is the link between customers and development team, he ensures that deliverables are in line with customers’ expectation and that stakeholders’ interests are fulfilled. He has also the task to fill out customer-centric items (typically '''user stories'''), ranks and prioritizes them before adds them to '''Product Backlog'''.

Usually development teams have only one Product owner, but differently from the Scrum master, he only takes care of the business side and does not interfere with the scrum team about the technological issues. At the beginning of each Sprint the Product Owner holds a Sprint Planning Meeting to state on which Product Backlog Items Scrum team will go to work during the next Sprint. In this phase he defines what are the most important items for that business, in according to customer’s needs.

===Development Team===
Development team task is to provide Product Backlog Items (PBIs) at the end of every Sprint in according with customers’ requirements after negotiating commitments with the Product Owner.
Usually each team is composed by '''cross-functional members''' that allow an all-round software development; the main figures that there must be are a mix of software engineers, architects, programmers, analysts, QA experts, testers, and UI designers.

The size of the team is an important point, the group members' number influences capacity of people to communicate and work together: it is recommended that a scrum team is composed not more than nine people, usually seven.

Another important characteristic is the Self-organization of the group which facilitates members’ creativity and increases team cohesiveness: for this reason it is better to not change members of a team after they have worked together, especially if they had success in their project. After working together team members gain a mutual understanding that increases their capacity of team working, this synergy cannot be acquired if team are continuously changed.

A further point that characterized the good outcomes of a scrum team is location: people are most successful when located in the same room, particularly for the first few Sprints: this facilitates communication and information sharing.

====Team self-organization====
Team self-organization is a crucial point in the scrum methodology : with this concept it means that “it is told developer what needs to be done not how to do it”, they can autonomously choose the way to reach commitments.
As it is said previously during Sprint execution, team members develop an intrinsic interest in shared goals and learn to manage each other to achieve them, for this reason self-organizing teams can radically outperform larger than traditionally managed teams. It has to be specified that an optimal self-organization takes time: it may be possible that for the first few sprints developers perform worse than when they work in the traditional way.

Some requirements are necessary to gain a good team self-organization:
*members are committed to clear, short-term goals;
*members can gauge the group’s progress;
*members can observe each other’s contribution;
*members feel safe to give each other unvarnished feedback.<ref name='James'>M. James,2010,Scrum Reference Card, Michael James,[[http://scrumreferencecard.com/]]</ref>

Conversely there are some conditions that can hander self-organization:
*geographical distribution: it is better if the whole team work in a room;
*boss/work dynamics: each member has to consider the others as peer to facilitate a fair communication between them;
*part-time team members;
*interruptions unrelated to Sprint goals.

===Scrum Master===
The scrum master worries that Scrum team can work without obstacles but he has no management authority over them. Essentially he has the aim to:
*create an environment to promote team self-organization;
*support team in the achievement of expected goals;
*ensure that events (e.g. daily Scrum meeting) take place in the right way;
*keep '''Scrum artefacts''' visible ('''Product Backlog''', '''Sprint Backlog''', '''Sprint burndown chart''' …).

==Sprint==
Sprint (or iteration) is the fundamental unit in which the work is divided; it is characterized by a fixed length of 2 weeks or 30 days and by a goal to achieve. At the beginning of each sprint Scrum team , Product Owner , Scrum Master and sometimes also stakeholders hold a meeting, called Sprint Planning meeting whose output is the Sprint Backlog where goals and requirements of the next Sprint are defined. Then other meetings inside development team will be held in order to define in more detail how achieving the common goals stated in the previous meeting.
==Scrum Meetings==
[[File:Scrum_meetings.png|350px|thumb|right|Scrum Meetings<ref name='James'></ref>]]
Meeting are a fundamental tool used during the whole Scrum process. Usually they are facilitated by the Scrum master who has no decision-making authority over them . There are different typologies of meetings according to the different phase of the process in which we are.
===Sprint Planning Meeting===
At the beginning of each Sprint, the Product Owner and team hold a Sprint Planning Meeting to define on which '''Product Backlog Items (PBIs)''' they will go to work during the next Sprint. "The Product Owner is responsible for declaring which items are the most important to the business. The team is responsible for selecting the amount of work they feel they can implement" (''M. James, 2010'')<ref name='James'></ref>.In this phase in perfect Lean perspective the team “pulls” work from the Product Backlog to the Sprint Backlog. At the end of the meeting the selected items are broken into a provisional list of Sprint task. The maximum time that can be used to do Planning meeting, known as '''timebox''', is of eight hours.

===Daily Scrum and Sprint Execution===
During the sprint every day members of the Scrum team hold a fifteen minutes meeting where they take stock of the situation. Usually they speak about what they did previous day, which impediments they faced and what they are going to do in the current day. To make these meetings shorter it is better that people are standing.
During sprint execution it is common to find out additional tasks necessary to achieve sprint goal; to keep the control over processes during sprint development it could be useful to maintain a current '''Sprint Task List''', a '''Sprint Burndown Chart''', and an '''Impediments List''': these are some artefacts that allow developer to understand where the project is located.

===Sprint Review Meeting===
At the end of every Sprint it is held a Review meeting where the scrum team has to explain to the Product Owner what they did during the previous sprint. Usually this meeting consists in a live demonstration of the working product increment after which Product Owner states which Items can be considered as done.
Items which are declared not done have to return to the Product Backlog to be ranked and reprioritized by the Product Owner with the help of the Scrum master. Last step of this meeting is to convert stakeholders’ feedback to a new Product Log, this task is consigned to both Product Owner and Scrum Master.
The Sprint Review Meeting is the appropriate meeting for external stakeholders (even end users) to attend.

===Sprint Retrospective Meeting===
During this meeting every member of the scrum team inspects his behaviour to identify some impediments that he faced during Sprint. There are mainly three kind of impediments in which developers can be involved:
*people who conduct performance evaluation are an obstacles to transparency of the team;
*human tendency of someone in the team to jump to conclusions and propose actions too quickly;
*geographical distribution of the team can be an impediments, team work better if they are delimited in a small place like a room.<ref name='James'></ref>

After identifying all these impediments Scrum master has the task to eliminate them.

===Backlog Refinement Meeting ===
Especially at the beginning of the project "most of the Product Backlog Items (PBIs) need refinement because they are too large and poorly understood" (''M. James, 2010'')<ref name='James'></ref>. In the Backlog Refinement Meeting, the team gave an estimation of the work left to complete Items in the Product Backlog and provides other technical information to help the Product Owner prioritize them.

==Artefacts==
[[File:Product_Backlog.png|200px|thumb|right|Product Backlog<ref name='James'></ref>]]
===Product Backlog===

It is defined before the project beginning and then upgraded during the Backlog Refinement meeting ; it is made up by the whole group of items which have to be completed during the project in order to realize the final product. Every item is ranked and constantly reprioritized by the Product Owner. It is important that Product Backlog Is visible to the stakeholders.

===Product Backlog Item (PBI)===
An item specifies what has to be done but not how do it. Usually they are written in a User story to be understood also by stakeholders. Every items has a work load of 2-3 days and requires 2-3 people. It represents the basic unit of Product backlog.
[[File:Sprint_Backlog.png|200px|thumb|right|Sprint Backlog<ref name='James'></ref>]]
===Sprint backlog===

It is defined at the beginning of each sprint during the Sprint Planning meeting where committed items and the main task that have to be done during the sprint are identified. It has to be visible to Scrum team and it can be upgraded during the sprint execution with additional task necessary to achieve the final goal.

===Sprint task===
Every item is divided into several tasks, each of them requires one day or less of work. A sprint task specifies how to achieve what is required by PBI. If the task takes more than one day of work, remaining effort is re-estimated daily, typically in hours.

===Sprint Burndown Chart===
[[File:Sprint_burndown_chart.png|300px|thumb|right|Sprint Burndown Chart<ref name='James'></ref>]]
This tool is used to facilitate self-organization of the team. It indicates the total remaining team task hours within one Sprint. Usually chart shows a decreasing line but if there are some re-estimation it may be possible that line increase for then going down. As picture shows it has a time line in the x axis and the remaining hours of work within one Sprint in the y axis. The advantage of this tool is to show at a first sight at which point of the project you are and the work that is left to complete the Sprint. It is important that this tool is used only as help to Scrum team; in some situations it could become a constraint for developers, in this case Scrum Master has to remove this chart from the room.

=Limitations=
Scrum method was often used in the object-oriented software development. Actually this technique are applied not only on software but also on other products from different sectors like wheelchairs, semiconductors and mortgages.
Scrum has to be used in those projects where people cannot rely on the plan-driven approaches like Waterfall, because of unknown requirements and technology.
[[File:Graph.png|300px|thumb|right|Predictability of a Project<ref name='James'></ref>]]
Conversely if the projects is placed under precise and stable conditions it is better to use one of the traditional model which allow to have a fixed planning over the whole project. In this case Scrum method would involve in a waste of resources and money because he is working on a field that is not its responsibility.

Michael James in his “Scrum Reference card” explains with a simple graphics in which conditions Scrum should be used and which ones are not. James defines the predictability of the projects on the base of two features: knowledge of the requirements and knowledge of the level of technology required. A project which provides known requirements and a known level of technology should be carried out with a plan-driven model. It these conditions are not met it is better to use an empirical approach like Scrum.<ref name='James'></ref>

=References=
<references/>

Scrum Methodology in Agile Software Development

2015-09-27T11:26:29Z

S150821: /* Scrum Methodology */

Today market is affected by uncertainly and sudden changes, in these conditions most of the models used in the 20th century to develop software are not still appropriate.[[Wikipedia:Waterfall model | Waterfall model]] , probably the most famous between them, is characterized by a stiff structure which can’t cope with the turbulent needs of actual market.
In recent years many innovations are been enhanced in software engineering with a particular focus on the flexibility of these methods in order to cope with the customers' and markets' needs; surely [[Wikipedia: Agile Software Development |Agile Software Development (ASD)]] is between them.

ASD embraces the principles of lean production by applying them in software development to avoid waste and increase responsiveness to change. It represents the solution to the unpredictability of the market where the capacity "to welcome change even late in development" (''K. Beck et all, 2001'')<ref name='Manifesto'></ref> to satisfy customers is required.
This article deals with Agile Software Development with a particular focus on one of its most used technique : '''Scrum Methodology'''.

=Scrum Methodology=
Scrum is an iterative method used to develop software, it can be placed inside the group of methods which are used in '''ASD'''. This word is taken from rugby and represents that phase of the match where an ordered formation of players, with arms interlocked and heads down, push forward against a similar group to gain possession of the ball<ref name='Cohen'></ref>. This method provides that "work is divided into small chunks to manage complexity and to get early feedback from customers and end users" (''S. Augustine, 2005'')<ref>S. Augustine,2005,Prentice Hall PTR,Managing Agile Projects</ref>; software development is carried out by small working team that allow rapid adjustment during the process and a quick delivery of the final product.

==Agile Software Development==
Some practitioners believed that traditional [[Wikipedia:Iterative model |Iterative model]] was not so responsive to changes that market required. They thought that to be Agile a process needs to accept change rather than stress predictability and that methods used to develop software has to respond to change as quickly as it arose rather than prevent changes.<ref name='Cohen'>D.Cohen,M.Lindval,P. Costa,Fraunhofer Center Maryland, Agile Software Development</ref>

It was in these circumstances that practitioners as Mary Poppendieck and Bob Charet started to take inspiration from Lean manufacturing principles and apply them to software development.
These are the main points ,according to Poppendieck, which make Lean Production so successful and that can be applied to software development:

*elimination of waste that does not add value to the customer such as diagram and models that do not add value to the final deliverable;
*minimize inventory such as requirements and design documents;
*maximize flow by using iterative development to reduce development time;
*pull from demand;
*empower workers that means “tell developer what needs to be done not how to do it";
*meet customer requirements – work closely with the customer, allowing them to change their minds
*do it right the first time – test early and refactor when necessary;
*abolish local optimization – flexibly manage scope;
*partner with suppliers – avoid adversarial relationships, work towards developing the best software;
*create a culture of continuous improvement – allow the process to improve, learn from mistakes and successes.<ref name='Cohen'></ref><ref>M. Poppendieck, T. Poppendieck, 2003, Addison Wesley, Lean Software Development: An Agile Toolkit[[http://www.poppendieck.com/]]</ref>

===Manifesto for the Agile Software development===
A few years before Poppoendieck’s publication on February 2001 main principles of Agile Software development were stated by a group of seventeen software developers which published “Manifesto for the Agile Software Development”.<ref name='Manifesto'>K. Beck et all., 2001, Manifesto for Agile Software Development[http://www.agilemanifesto.org/]</ref>

From reading these few words it is possible to identify what are the main innovations that ASD introduced in Software development:
[[File:Agilemanifesto.jpg|400px|thumb|right|Manifesto for the Agile Software development<ref name='Manifesto'></ref>]]

*'''“Individuals and interactions”''' : with these words founders want to remark the power of human being creativity, and his ability to collaborate with other similar. The stiffness of Waterfall model is instead represented by “processes and tools” where people has to follow only what the plan requires.
*'''“Working software “''' : there is a clear reference to the new way to develop software where at every iteration a working program is realised, differently from the earlier model in which a working program couldn’t be seen until the end of the project. This feature is put over the “comprehensive documentation” which characterizes especially Waterfall model.
*'''“Customer collaboration”''' : means that there must be a straight relationship between customer and developer in order to define time by time the projects requirements and evaluate every realise.
*'''“Responding to change over following a plan”''' : this sentence encloses the essence of Agile software Development that is to cope with turbulent markets by being flexible and by responding quickly to change, instead of being bound by planning. This concept is remarked by the founders in one of the twelve principles which follow the manifesto which says “Welcome changing requirements, even late in development […]”.

=Application=
[[File:Scrum_Framework.png|350px|thumb|right|Scrum Framework]]
There are two concepts that are at the basement of Scrum methodology: '''iterative development''' and '''team working'''. Developing in iterations allow Scrum team to adapt quickly to changing requirements, while working in close location and focusing on communication allow team to make decisions and act on them immediately rather than wait on correspondence.<ref name='Cohen'></ref>

Basically Scrum consists in a sequence of fixed-length iterations called [[Sprint:http://apppm.man.dtu.dk/index.php?title=Scrum_Methodology_in_Agile_Software_Development&action=submit#Sprint|Sprint]] managed by one or more '''cross-functional and self-organizing teams''' each composed by seven people that aim at a common goal and that usually work only on the software development. There are instead other two figures that manage all things that are in support of the development process: one is '''Product Owner''' who mainly handles customers contacts and the other is '''Scrum Master''' whose main task is to ensure that development team can work without obstacles.

Each sprint usually lasts from 2 to 4 weeks, in this period there are at least one meeting between the Product Owner and Development Team to define the main objectives; then there are short daily meetings held every morning to enhance communication and inform customers, developers, and managers on the status of the project, identify any problems encountered, and keep the entire team focused on a common goal.<ref name='Cohen'></ref>

==Main figures in Scrum==
===Product Owner===
Product owner is the link between customers and development team, he ensures that deliverables are in line with customers’ expectation and that stakeholders’ interests are fulfilled. He has also the task to fill out customer-centric items (typically '''user stories'''), ranks and prioritizes them before adds them to '''Product Backlog'''.

Usually development teams have only one Product owner, but differently from the Scrum master, he only takes care of the business side and does not interfere with the scrum team about the technological issues. At the beginning of each Sprint the Product Owner holds a Sprint Planning Meeting to state on which Product Backlog Items Scrum team will go to work during the next Sprint. In this phase he defines what are the most important items for that business, in according to customer’s needs.

===Development Team===
Development team task is to provide Product Backlog Items (PBIs) at the end of every Sprint in according with customers’ requirements after negotiating commitments with the Product Owner.
Usually each team is composed by '''cross-functional members''' that allow an all-round software development; the main figures that there must be are a mix of software engineers, architects, programmers, analysts, QA experts, testers, and UI designers.

The size of the team is an important point, the group members' number influences capacity of people to communicate and work together: it is recommended that a scrum team is composed not more than nine people, usually seven.

Another important characteristic is the Self-organization of the group which facilitates members’ creativity and increases team cohesiveness: for this reason it is better to not change members of a team after they have worked together, especially if they had success in their project. After working together team members gain a mutual understanding that increases their capacity of team working, this synergy cannot be acquired if team are continuously changed.

A further point that characterized the good outcomes of a scrum team is location: people are most successful when located in the same room, particularly for the first few Sprints: this facilitates communication and information sharing.

====Team self-organization====
Team self-organization is a crucial point in the scrum methodology : with this concept it means that “it is told developer what needs to be done not how to do it”, they can autonomously choose the way to reach commitments.
As it is said previously during Sprint execution, team members develop an intrinsic interest in shared goals and learn to manage each other to achieve them, for this reason self-organizing teams can radically outperform larger than traditionally managed teams. It has to be specified that an optimal self-organization takes time: it may be possible that for the first few sprints developers perform worse than when they work in the traditional way.

Some requirements are necessary to gain a good team self-organization:
*members are committed to clear, short-term goals;
*members can gauge the group’s progress;
*members can observe each other’s contribution;
*members feel safe to give each other unvarnished feedback.<ref name='James'>M. James,2010,Scrum Reference Card, Michael James,[[http://scrumreferencecard.com/]]</ref>

Conversely there are some conditions that can hander self-organization:
*geographical distribution: it is better if the whole team work in a room;
*boss/work dynamics: each member has to consider the others as peer to facilitate a fair communication between them;
*part-time team members;
*interruptions unrelated to Sprint goals.

===Scrum Master===
The scrum master worries that Scrum team can work without obstacles but he has no management authority over them. Essentially he has the aim to:
*create an environment to promote team self-organization;
*support team in the achievement of expected goals;
*ensure that events (e.g. daily Scrum meeting) take place in the right way;
*keep '''Scrum artefacts''' visible ('''Product Backlog''', '''Sprint Backlog''', '''Sprint burndown chart''' …).

==Sprint==
Sprint (or iteration) is the fundamental unit in which the work is divided; it is characterized by a fixed length of 2 weeks or 30 days and by a goal to achieve. At the beginning of each sprint Scrum team , Product Owner , Scrum Master and sometimes also stakeholders hold a meeting, called Sprint Planning meeting whose output is the Sprint Backlog where goals and requirements of the next Sprint are defined. Then other meetings inside development team will be held in order to define in more detail how achieving the common goals stated in the previous meeting.
==Scrum Meetings==
[[File:Scrum_meetings.png|350px|thumb|right|Scrum Meetings<ref name='James'></ref>]]
Meeting are a fundamental tool used during the whole Scrum process. Usually they are facilitated by the Scrum master who has no decision-making authority over them . There are different typologies of meetings according to the different phase of the process in which we are.
===Sprint Planning Meeting===
At the beginning of each Sprint, the Product Owner and team hold a Sprint Planning Meeting to define on which '''Product Backlog Items (PBIs)''' they will go to work during the next Sprint. "The Product Owner is responsible for declaring which items are the most important to the business. The team is responsible for selecting the amount of work they feel they can implement" (''M. James, 2010'')<ref name='James'></ref>.In this phase in perfect Lean perspective the team “pulls” work from the Product Backlog to the Sprint Backlog. At the end of the meeting the selected items are broken into a provisional list of Sprint task. The maximum time that can be used to do Planning meeting, known as '''timebox''', is of eight hours.

===Daily Scrum and Sprint Execution===
During the sprint every day members of the Scrum team hold a fifteen minutes meeting where they take stock of the situation. Usually they speak about what they did previous day, which impediments they faced and what they are going to do in the current day. To make these meetings shorter it is better that people are standing.
During sprint execution it is common to find out additional tasks necessary to achieve sprint goal; to keep the control over processes during sprint development it could be useful to maintain a current '''Sprint Task List''', a '''Sprint Burndown Chart''', and an '''Impediments List''': these are some artefacts that allow developer to understand where the project is located.

===Sprint Review Meeting===
At the end of every Sprint it is held a Review meeting where the scrum team has to explain to the Product Owner what they did during the previous sprint. Usually this meeting consists in a live demonstration of the working product increment after which Product Owner states which Items can be considered as done.
Items which are declared not done have to return to the Product Backlog to be ranked and reprioritized by the Product Owner with the help of the Scrum master. Last step of this meeting is to convert stakeholders’ feedback to a new Product Log, this task is consigned to both Product Owner and Scrum Master.
The Sprint Review Meeting is the appropriate meeting for external stakeholders (even end users) to attend.

===Sprint Retrospective Meeting===
During this meeting every member of the scrum team inspects his behaviour to identify some impediments that he faced during Sprint. There are mainly three kind of impediments in which developers can be involved:
*people who conduct performance evaluation are an obstacles to transparency of the team;
*human tendency of someone in the team to jump to conclusions and propose actions too quickly;
*geographical distribution of the team can be an impediments, team work better if they are delimited in a small place like a room.<ref name='James'></ref>

After identifying all these impediments Scrum master has the task to eliminate them.

===Backlog Refinement Meeting ===
Especially at the beginning of the project "most of the Product Backlog Items (PBIs) need refinement because they are too large and poorly understood" (''M. James, 2010'')<ref name='James'></ref>. In the Backlog Refinement Meeting, the team gave an estimation of the work left to complete Items in the Product Backlog and provides other technical information to help the Product Owner prioritize them.

==Artefacts==
[[File:Product_Backlog.png|200px|thumb|right|Product Backlog<ref name='James'></ref>]]
===Product Backlog===

It is defined before the project beginning and then upgraded during the Backlog Refinement meeting ; it is made up by the whole group of items which have to be completed during the project in order to realize the final product. Every item is ranked and constantly reprioritized by the Product Owner. It is important that Product Backlog Is visible to the stakeholders.

===Product Backlog Item (PBI)===
An item specifies what has to be done but not how do it. Usually they are written in a User story to be understood also by stakeholders. Every items has a work load of 2-3 days and requires 2-3 people. It represents the basic unit of Product backlog.
[[File:Sprint_Backlog.png|200px|thumb|right|Sprint Backlog<ref name='James'></ref>]]
===Sprint backlog===

It is defined at the beginning of each sprint during the Sprint Planning meeting where committed items and the main task that have to be done during the sprint are identified. It has to be visible to Scrum team and it can be upgraded during the sprint execution with additional task necessary to achieve the final goal.

===Sprint task===
Every item is divided into several tasks, each of them requires one day or less of work. A sprint task specifies how to achieve what is required by PBI. If the task takes more than one day of work, remaining effort is re-estimated daily, typically in hours.

===Sprint Burndown Chart===
[[File:Sprint_burndown_chart.png|300px|thumb|right|Sprint Burndown Chart<ref name='James'></ref>]]
This tool is used to facilitate self-organization of the team. It indicates the total remaining team task hours within one Sprint. Usually chart shows a decreasing line but if there are some re-estimation it may be possible that line increase for then going down. As picture shows it has a time line in the x axis and the remaining hours of work within one Sprint in the y axis. The advantage of this tool is to show at a first sight at which point of the project you are and the work that is left to complete the Sprint. It is important that this tool is used only as help to Scrum team; in some situations it could become a constraint for developers, in this case Scrum Master has to remove this chart from the room.

=Limitations=
Scrum method was often used in the object-oriented software development. Actually this technique are applied not only on software but also on other products from different sectors like wheelchairs, semiconductors and mortgages.
Scrum has to be used in those projects where people cannot rely on the plan-driven approaches like Waterfall, because of unknown requirements and technology.
[[File:Graph.png|300px|thumb|right|Predictability of a Project<ref name='James'></ref>]]
Conversely if the projects is placed under precise and stable conditions it is better to use one of the traditional model which allow to have a fixed planning over the whole project. In this case Scrum method would involve in a waste of resources and money because he is working on a field that is not its responsibility.

Michael James in his “Scrum Reference card” explains with a simple graphics in which conditions Scrum should be used and which ones are not. James defines the predictability of the projects on the base of two features: knowledge of the requirements and knowledge of the level of technology required. A project which provides known requirements and a known level of technology should be carried out with a plan-driven model. It these conditions are not met it is better to use an empirical approach like Scrum.<ref name='James'></ref>

=References=
<references/>

Scrum Methodology in Agile Software Development

2015-09-27T11:22:23Z

S150821: /* Manifesto for the Agile Software development */

Today market is affected by uncertainly and sudden changes, in these conditions most of the models used in the 20th century to develop software are not still appropriate.[[Wikipedia:Waterfall model | Waterfall model]] , probably the most famous between them, is characterized by a stiff structure which can’t cope with the turbulent needs of actual market.
In recent years many innovations are been enhanced in software engineering with a particular focus on the flexibility of these methods in order to cope with the customers' and markets' needs; surely [[Wikipedia: Agile Software Development |Agile Software Development (ASD)]] is between them.

ASD embraces the principles of lean production by applying them in software development to avoid waste and increase responsiveness to change. It represents the solution to the unpredictability of the market where the capacity "to welcome change even late in development" (''K. Beck et all, 2001'')<ref name='Manifesto'></ref> to satisfy customers is required.
This article deals with Agile Software Development with a particular focus on one of its most used technique : '''Scrum Methodology'''.

=Scrum Methodology=
Scrum is an iterative method used to develop software, it can be placed inside the group of methods which are used in '''Agile Software Development'''. This word is taken from rugby and represents that phase of the match where an ordered formation of players, with arms interlocked and heads down, push forward against a similar group to gain possession of the ball. This method provides that "work is divided into small chunks to manage complexity and to get early feedback from customers and end users" (''S. Augustine, 2005'')<ref>S. Augustine,2005,Prentice Hall PTR,Managing Agile Projects</ref>; software development is carried out by small working team that allow rapid adjustment during the process and a quick delivery of the final product.

==Agile Software Development==
Some practitioners believed that traditional [[Wikipedia:Iterative model |Iterative model]] was not so responsive to changes that market required. They thought that to be Agile a process needs to accept change rather than stress predictability and that methods used to develop software has to respond to change as quickly as it arose rather than prevent changes.<ref name='Cohen'>D.Cohen,M.Lindval,P. Costa,Fraunhofer Center Maryland, Agile Software Development</ref>

It was in these circumstances that practitioners as Mary Poppendieck and Bob Charet started to take inspiration from Lean manufacturing principles and apply them to software development.
These are the main points ,according to Poppendieck, which make Lean Production so successful and that can be applied to software development:

*elimination of waste that does not add value to the customer such as diagram and models that do not add value to the final deliverable;
*minimize inventory such as requirements and design documents;
*maximize flow by using iterative development to reduce development time;
*pull from demand;
*empower workers that means “tell developer what needs to be done not how to do it";
*meet customer requirements – work closely with the customer, allowing them to change their minds
*do it right the first time – test early and refactor when necessary;
*abolish local optimization – flexibly manage scope;
*partner with suppliers – avoid adversarial relationships, work towards developing the best software;
*create a culture of continuous improvement – allow the process to improve, learn from mistakes and successes.<ref name='Cohen'></ref><ref>M. Poppendieck, T. Poppendieck, 2003, Addison Wesley, Lean Software Development: An Agile Toolkit[[http://www.poppendieck.com/]]</ref>

===Manifesto for the Agile Software development===
A few years before Poppoendieck’s publication on February 2001 main principles of Agile Software development were stated by a group of seventeen software developers which published “Manifesto for the Agile Software Development”.<ref name='Manifesto'>K. Beck et all., 2001, Manifesto for Agile Software Development[http://www.agilemanifesto.org/]</ref>

From reading these few words it is possible to identify what are the main innovations that ASD introduced in Software development:
[[File:Agilemanifesto.jpg|400px|thumb|right|Manifesto for the Agile Software development<ref name='Manifesto'></ref>]]

*'''“Individuals and interactions”''' : with these words founders want to remark the power of human being creativity, and his ability to collaborate with other similar. The stiffness of Waterfall model is instead represented by “processes and tools” where people has to follow only what the plan requires.
*'''“Working software “''' : there is a clear reference to the new way to develop software where at every iteration a working program is realised, differently from the earlier model in which a working program couldn’t be seen until the end of the project. This feature is put over the “comprehensive documentation” which characterizes especially Waterfall model.
*'''“Customer collaboration”''' : means that there must be a straight relationship between customer and developer in order to define time by time the projects requirements and evaluate every realise.
*'''“Responding to change over following a plan”''' : this sentence encloses the essence of Agile software Development that is to cope with turbulent markets by being flexible and by responding quickly to change, instead of being bound by planning. This concept is remarked by the founders in one of the twelve principles which follow the manifesto which says “Welcome changing requirements, even late in development […]”.

=Application=
[[File:Scrum_Framework.png|350px|thumb|right|Scrum Framework]]
There are two concepts that are at the basement of Scrum methodology: '''iterative development''' and '''team working'''. Developing in iterations allow Scrum team to adapt quickly to changing requirements, while working in close location and focusing on communication allow team to make decisions and act on them immediately rather than wait on correspondence.<ref name='Cohen'></ref>

Basically Scrum consists in a sequence of fixed-length iterations called [[Sprint:http://apppm.man.dtu.dk/index.php?title=Scrum_Methodology_in_Agile_Software_Development&action=submit#Sprint|Sprint]] managed by one or more '''cross-functional and self-organizing teams''' each composed by seven people that aim at a common goal and that usually work only on the software development. There are instead other two figures that manage all things that are in support of the development process: one is '''Product Owner''' who mainly handles customers contacts and the other is '''Scrum Master''' whose main task is to ensure that development team can work without obstacles.

Each sprint usually lasts from 2 to 4 weeks, in this period there are at least one meeting between the Product Owner and Development Team to define the main objectives; then there are short daily meetings held every morning to enhance communication and inform customers, developers, and managers on the status of the project, identify any problems encountered, and keep the entire team focused on a common goal.<ref name='Cohen'></ref>

==Main figures in Scrum==
===Product Owner===
Product owner is the link between customers and development team, he ensures that deliverables are in line with customers’ expectation and that stakeholders’ interests are fulfilled. He has also the task to fill out customer-centric items (typically '''user stories'''), ranks and prioritizes them before adds them to '''Product Backlog'''.

Usually development teams have only one Product owner, but differently from the Scrum master, he only takes care of the business side and does not interfere with the scrum team about the technological issues. At the beginning of each Sprint the Product Owner holds a Sprint Planning Meeting to state on which Product Backlog Items Scrum team will go to work during the next Sprint. In this phase he defines what are the most important items for that business, in according to customer’s needs.

===Development Team===
Development team task is to provide Product Backlog Items (PBIs) at the end of every Sprint in according with customers’ requirements after negotiating commitments with the Product Owner.
Usually each team is composed by '''cross-functional members''' that allow an all-round software development; the main figures that there must be are a mix of software engineers, architects, programmers, analysts, QA experts, testers, and UI designers.

The size of the team is an important point, the group members' number influences capacity of people to communicate and work together: it is recommended that a scrum team is composed not more than nine people, usually seven.

Another important characteristic is the Self-organization of the group which facilitates members’ creativity and increases team cohesiveness: for this reason it is better to not change members of a team after they have worked together, especially if they had success in their project. After working together team members gain a mutual understanding that increases their capacity of team working, this synergy cannot be acquired if team are continuously changed.

A further point that characterized the good outcomes of a scrum team is location: people are most successful when located in the same room, particularly for the first few Sprints: this facilitates communication and information sharing.

====Team self-organization====
Team self-organization is a crucial point in the scrum methodology : with this concept it means that “it is told developer what needs to be done not how to do it”, they can autonomously choose the way to reach commitments.
As it is said previously during Sprint execution, team members develop an intrinsic interest in shared goals and learn to manage each other to achieve them, for this reason self-organizing teams can radically outperform larger than traditionally managed teams. It has to be specified that an optimal self-organization takes time: it may be possible that for the first few sprints developers perform worse than when they work in the traditional way.

Some requirements are necessary to gain a good team self-organization:
*members are committed to clear, short-term goals;
*members can gauge the group’s progress;
*members can observe each other’s contribution;
*members feel safe to give each other unvarnished feedback.<ref name='James'>M. James,2010,Scrum Reference Card, Michael James,[[http://scrumreferencecard.com/]]</ref>

Conversely there are some conditions that can hander self-organization:
*geographical distribution: it is better if the whole team work in a room;
*boss/work dynamics: each member has to consider the others as peer to facilitate a fair communication between them;
*part-time team members;
*interruptions unrelated to Sprint goals.

===Scrum Master===
The scrum master worries that Scrum team can work without obstacles but he has no management authority over them. Essentially he has the aim to:
*create an environment to promote team self-organization;
*support team in the achievement of expected goals;
*ensure that events (e.g. daily Scrum meeting) take place in the right way;
*keep '''Scrum artefacts''' visible ('''Product Backlog''', '''Sprint Backlog''', '''Sprint burndown chart''' …).

==Sprint==
Sprint (or iteration) is the fundamental unit in which the work is divided; it is characterized by a fixed length of 2 weeks or 30 days and by a goal to achieve. At the beginning of each sprint Scrum team , Product Owner , Scrum Master and sometimes also stakeholders hold a meeting, called Sprint Planning meeting whose output is the Sprint Backlog where goals and requirements of the next Sprint are defined. Then other meetings inside development team will be held in order to define in more detail how achieving the common goals stated in the previous meeting.
==Scrum Meetings==
[[File:Scrum_meetings.png|350px|thumb|right|Scrum Meetings<ref name='James'></ref>]]
Meeting are a fundamental tool used during the whole Scrum process. Usually they are facilitated by the Scrum master who has no decision-making authority over them . There are different typologies of meetings according to the different phase of the process in which we are.
===Sprint Planning Meeting===
At the beginning of each Sprint, the Product Owner and team hold a Sprint Planning Meeting to define on which '''Product Backlog Items (PBIs)''' they will go to work during the next Sprint. "The Product Owner is responsible for declaring which items are the most important to the business. The team is responsible for selecting the amount of work they feel they can implement" (''M. James, 2010'')<ref name='James'></ref>.In this phase in perfect Lean perspective the team “pulls” work from the Product Backlog to the Sprint Backlog. At the end of the meeting the selected items are broken into a provisional list of Sprint task. The maximum time that can be used to do Planning meeting, known as '''timebox''', is of eight hours.

===Daily Scrum and Sprint Execution===
During the sprint every day members of the Scrum team hold a fifteen minutes meeting where they take stock of the situation. Usually they speak about what they did previous day, which impediments they faced and what they are going to do in the current day. To make these meetings shorter it is better that people are standing.
During sprint execution it is common to find out additional tasks necessary to achieve sprint goal; to keep the control over processes during sprint development it could be useful to maintain a current '''Sprint Task List''', a '''Sprint Burndown Chart''', and an '''Impediments List''': these are some artefacts that allow developer to understand where the project is located.

===Sprint Review Meeting===
At the end of every Sprint it is held a Review meeting where the scrum team has to explain to the Product Owner what they did during the previous sprint. Usually this meeting consists in a live demonstration of the working product increment after which Product Owner states which Items can be considered as done.
Items which are declared not done have to return to the Product Backlog to be ranked and reprioritized by the Product Owner with the help of the Scrum master. Last step of this meeting is to convert stakeholders’ feedback to a new Product Log, this task is consigned to both Product Owner and Scrum Master.
The Sprint Review Meeting is the appropriate meeting for external stakeholders (even end users) to attend.

===Sprint Retrospective Meeting===
During this meeting every member of the scrum team inspects his behaviour to identify some impediments that he faced during Sprint. There are mainly three kind of impediments in which developers can be involved:
*people who conduct performance evaluation are an obstacles to transparency of the team;
*human tendency of someone in the team to jump to conclusions and propose actions too quickly;
*geographical distribution of the team can be an impediments, team work better if they are delimited in a small place like a room.<ref name='James'></ref>

After identifying all these impediments Scrum master has the task to eliminate them.

===Backlog Refinement Meeting ===
Especially at the beginning of the project "most of the Product Backlog Items (PBIs) need refinement because they are too large and poorly understood" (''M. James, 2010'')<ref name='James'></ref>. In the Backlog Refinement Meeting, the team gave an estimation of the work left to complete Items in the Product Backlog and provides other technical information to help the Product Owner prioritize them.

==Artefacts==
[[File:Product_Backlog.png|200px|thumb|right|Product Backlog<ref name='James'></ref>]]
===Product Backlog===

It is defined before the project beginning and then upgraded during the Backlog Refinement meeting ; it is made up by the whole group of items which have to be completed during the project in order to realize the final product. Every item is ranked and constantly reprioritized by the Product Owner. It is important that Product Backlog Is visible to the stakeholders.

===Product Backlog Item (PBI)===
An item specifies what has to be done but not how do it. Usually they are written in a User story to be understood also by stakeholders. Every items has a work load of 2-3 days and requires 2-3 people. It represents the basic unit of Product backlog.
[[File:Sprint_Backlog.png|200px|thumb|right|Sprint Backlog<ref name='James'></ref>]]
===Sprint backlog===

It is defined at the beginning of each sprint during the Sprint Planning meeting where committed items and the main task that have to be done during the sprint are identified. It has to be visible to Scrum team and it can be upgraded during the sprint execution with additional task necessary to achieve the final goal.

===Sprint task===
Every item is divided into several tasks, each of them requires one day or less of work. A sprint task specifies how to achieve what is required by PBI. If the task takes more than one day of work, remaining effort is re-estimated daily, typically in hours.

===Sprint Burndown Chart===
[[File:Sprint_burndown_chart.png|300px|thumb|right|Sprint Burndown Chart<ref name='James'></ref>]]
This tool is used to facilitate self-organization of the team. It indicates the total remaining team task hours within one Sprint. Usually chart shows a decreasing line but if there are some re-estimation it may be possible that line increase for then going down. As picture shows it has a time line in the x axis and the remaining hours of work within one Sprint in the y axis. The advantage of this tool is to show at a first sight at which point of the project you are and the work that is left to complete the Sprint. It is important that this tool is used only as help to Scrum team; in some situations it could become a constraint for developers, in this case Scrum Master has to remove this chart from the room.

=Limitations=
Scrum method was often used in the object-oriented software development. Actually this technique are applied not only on software but also on other products from different sectors like wheelchairs, semiconductors and mortgages.
Scrum has to be used in those projects where people cannot rely on the plan-driven approaches like Waterfall, because of unknown requirements and technology.
[[File:Graph.png|300px|thumb|right|Predictability of a Project<ref name='James'></ref>]]
Conversely if the projects is placed under precise and stable conditions it is better to use one of the traditional model which allow to have a fixed planning over the whole project. In this case Scrum method would involve in a waste of resources and money because he is working on a field that is not its responsibility.

Michael James in his “Scrum Reference card” explains with a simple graphics in which conditions Scrum should be used and which ones are not. James defines the predictability of the projects on the base of two features: knowledge of the requirements and knowledge of the level of technology required. A project which provides known requirements and a known level of technology should be carried out with a plan-driven model. It these conditions are not met it is better to use an empirical approach like Scrum.<ref name='James'></ref>

=References=
<references/>

Scrum Methodology in Agile Software Development

2015-09-27T10:47:45Z

S150821:

Today market is affected by uncertainly and sudden changes, in these conditions most of the models used in the 20th century to develop software are not still appropriate.[[Wikipedia:Waterfall model | Waterfall model]] , probably the most famous between them, is characterized by a stiff structure which can’t cope with the turbulent needs of actual market.
In recent years many innovations are been enhanced in software engineering with a particular focus on the flexibility of these methods in order to cope with the customers' and markets' needs; surely [[Wikipedia: Agile Software Development |Agile Software Development (ASD)]] is between them.

ASD embraces the principles of lean production by applying them in software development to avoid waste and increase responsiveness to change. It represents the solution to the unpredictability of the market where the capacity "to welcome change even late in development" (''K. Beck et all, 2001'')<ref name='Manifesto'></ref> to satisfy customers is required.
This article deals with Agile Software Development with a particular focus on one of its most used technique : '''Scrum Methodology'''.

=Scrum Methodology=
Scrum is an iterative method used to develop software, it can be placed inside the group of methods which are used in '''Agile Software Development'''. This word is taken from rugby and represents that phase of the match where an ordered formation of players, with arms interlocked and heads down, push forward against a similar group to gain possession of the ball. This method provides that "work is divided into small chunks to manage complexity and to get early feedback from customers and end users" (''S. Augustine, 2005'')<ref>S. Augustine,2005,Prentice Hall PTR,Managing Agile Projects</ref>; software development is carried out by small working team that allow rapid adjustment during the process and a quick delivery of the final product.

==Agile Software Development==
Some practitioners believed that traditional [[Wikipedia:Iterative model |Iterative model]] was not so responsive to changes that market required. They thought that to be Agile a process needs to accept change rather than stress predictability and that methods used to develop software has to respond to change as quickly as it arose rather than prevent changes.<ref name='Cohen'>D.Cohen,M.Lindval,P. Costa,Fraunhofer Center Maryland, Agile Software Development</ref>

It was in these circumstances that practitioners as Mary Poppendieck and Bob Charet started to take inspiration from Lean manufacturing principles and apply them to software development.
These are the main points ,according to Poppendieck, which make Lean Production so successful and that can be applied to software development:

*elimination of waste that does not add value to the customer such as diagram and models that do not add value to the final deliverable;
*minimize inventory such as requirements and design documents;
*maximize flow by using iterative development to reduce development time;
*pull from demand;
*empower workers that means “tell developer what needs to be done not how to do it";
*meet customer requirements – work closely with the customer, allowing them to change their minds
*do it right the first time – test early and refactor when necessary;
*abolish local optimization – flexibly manage scope;
*partner with suppliers – avoid adversarial relationships, work towards developing the best software;
*create a culture of continuous improvement – allow the process to improve, learn from mistakes and successes.<ref name='Cohen'></ref><ref>M. Poppendieck, T. Poppendieck, 2003, Addison Wesley, Lean Software Development: An Agile Toolkit[[http://www.poppendieck.com/]]</ref>

===Manifesto for the Agile Software development===
A few years before Poppoendieck’s publication on February 2001 main principles of Agile Software development were stated by a group of 17 software developers which published “Manifesto for the Agile Software Development”.<ref name='Manifesto'>K. Beck et all., 2001, Manifesto for Agile Software Development[http://www.agilemanifesto.org/]</ref>

From reading these few words it is possible to identify what are the main innovations that ASD introduced in Software development:
[[File:Agilemanifesto.jpg|400px|thumb|right|Manifesto for the Agile Software development<ref name='Manifesto'></ref>]]

*'''“Individuals and interactions”''' : with these words founders want to remark the power of human being creativity, and his ability to collaborate with other similar. The stiffness of Waterfall model is instead represented by “processes and tools” where people has to follow only what the plan requires.
*'''“Working software “''' : there is a clear reference to the new way to develop software where at every iteration a working program is realised, differently from the earlier model in which a working program couldn’t be seen until the end of the project. This feature is put over the “comprehensive documentation” which characterizes especially Waterfall model.
*'''“Customer collaboration”''' : means that there must be a straight relationship between customer and developer in order to define time by time the projects requirements and evaluate every realise.
*'''“Responding to change over following a plan”''' : this sentence encloses the essence of Agile software Development that is to cope with turbulent markets by being flexible and by responding quickly to change, instead of being bound by planning. This concept is remarked by the founders in one of the twelve principles which follow the manifesto which says “Welcome changing requirements, even late in development […]”.

=Application=
[[File:Scrum_Framework.png|350px|thumb|right|Scrum Framework]]
There are two concepts that are at the basement of Scrum methodology: '''iterative development''' and '''team working'''. Developing in iterations allow Scrum team to adapt quickly to changing requirements, while working in close location and focusing on communication allow team to make decisions and act on them immediately rather than wait on correspondence.<ref name='Cohen'></ref>

Basically Scrum consists in a sequence of fixed-length iterations called [[Sprint:http://apppm.man.dtu.dk/index.php?title=Scrum_Methodology_in_Agile_Software_Development&action=submit#Sprint|Sprint]] managed by one or more '''cross-functional and self-organizing teams''' each composed by seven people that aim at a common goal and that usually work only on the software development. There are instead other two figures that manage all things that are in support of the development process: one is '''Product Owner''' who mainly handles customers contacts and the other is '''Scrum Master''' whose main task is to ensure that development team can work without obstacles.

Each sprint usually lasts from 2 to 4 weeks, in this period there are at least one meeting between the Product Owner and Development Team to define the main objectives; then there are short daily meetings held every morning to enhance communication and inform customers, developers, and managers on the status of the project, identify any problems encountered, and keep the entire team focused on a common goal.<ref name='Cohen'></ref>

==Main figures in Scrum==
===Product Owner===
Product owner is the link between customers and development team, he ensures that deliverables are in line with customers’ expectation and that stakeholders’ interests are fulfilled. He has also the task to fill out customer-centric items (typically '''user stories'''), ranks and prioritizes them before adds them to '''Product Backlog'''.

Usually development teams have only one Product owner, but differently from the Scrum master, he only takes care of the business side and does not interfere with the scrum team about the technological issues. At the beginning of each Sprint the Product Owner holds a Sprint Planning Meeting to state on which Product Backlog Items Scrum team will go to work during the next Sprint. In this phase he defines what are the most important items for that business, in according to customer’s needs.

===Development Team===
Development team task is to provide Product Backlog Items (PBIs) at the end of every Sprint in according with customers’ requirements after negotiating commitments with the Product Owner.
Usually each team is composed by '''cross-functional members''' that allow an all-round software development; the main figures that there must be are a mix of software engineers, architects, programmers, analysts, QA experts, testers, and UI designers.

The size of the team is an important point, the group members' number influences capacity of people to communicate and work together: it is recommended that a scrum team is composed not more than nine people, usually seven.

Another important characteristic is the Self-organization of the group which facilitates members’ creativity and increases team cohesiveness: for this reason it is better to not change members of a team after they have worked together, especially if they had success in their project. After working together team members gain a mutual understanding that increases their capacity of team working, this synergy cannot be acquired if team are continuously changed.

A further point that characterized the good outcomes of a scrum team is location: people are most successful when located in the same room, particularly for the first few Sprints: this facilitates communication and information sharing.

====Team self-organization====
Team self-organization is a crucial point in the scrum methodology : with this concept it means that “it is told developer what needs to be done not how to do it”, they can autonomously choose the way to reach commitments.
As it is said previously during Sprint execution, team members develop an intrinsic interest in shared goals and learn to manage each other to achieve them, for this reason self-organizing teams can radically outperform larger than traditionally managed teams. It has to be specified that an optimal self-organization takes time: it may be possible that for the first few sprints developers perform worse than when they work in the traditional way.

Some requirements are necessary to gain a good team self-organization:
*members are committed to clear, short-term goals;
*members can gauge the group’s progress;
*members can observe each other’s contribution;
*members feel safe to give each other unvarnished feedback.<ref name='James'>M. James,2010,Scrum Reference Card, Michael James,[[http://scrumreferencecard.com/]]</ref>

Conversely there are some conditions that can hander self-organization:
*geographical distribution: it is better if the whole team work in a room;
*boss/work dynamics: each member has to consider the others as peer to facilitate a fair communication between them;
*part-time team members;
*interruptions unrelated to Sprint goals.

===Scrum Master===
The scrum master worries that Scrum team can work without obstacles but he has no management authority over them. Essentially he has the aim to:
*create an environment to promote team self-organization;
*support team in the achievement of expected goals;
*ensure that events (e.g. daily Scrum meeting) take place in the right way;
*keep '''Scrum artefacts''' visible ('''Product Backlog''', '''Sprint Backlog''', '''Sprint burndown chart''' …).

==Sprint==
Sprint (or iteration) is the fundamental unit in which the work is divided; it is characterized by a fixed length of 2 weeks or 30 days and by a goal to achieve. At the beginning of each sprint Scrum team , Product Owner , Scrum Master and sometimes also stakeholders hold a meeting, called Sprint Planning meeting whose output is the Sprint Backlog where goals and requirements of the next Sprint are defined. Then other meetings inside development team will be held in order to define in more detail how achieving the common goals stated in the previous meeting.
==Scrum Meetings==
[[File:Scrum_meetings.png|350px|thumb|right|Scrum Meetings<ref name='James'></ref>]]
Meeting are a fundamental tool used during the whole Scrum process. Usually they are facilitated by the Scrum master who has no decision-making authority over them . There are different typologies of meetings according to the different phase of the process in which we are.
===Sprint Planning Meeting===
At the beginning of each Sprint, the Product Owner and team hold a Sprint Planning Meeting to define on which '''Product Backlog Items (PBIs)''' they will go to work during the next Sprint. "The Product Owner is responsible for declaring which items are the most important to the business. The team is responsible for selecting the amount of work they feel they can implement" (''M. James, 2010'')<ref name='James'></ref>.In this phase in perfect Lean perspective the team “pulls” work from the Product Backlog to the Sprint Backlog. At the end of the meeting the selected items are broken into a provisional list of Sprint task. The maximum time that can be used to do Planning meeting, known as '''timebox''', is of eight hours.

===Daily Scrum and Sprint Execution===
During the sprint every day members of the Scrum team hold a fifteen minutes meeting where they take stock of the situation. Usually they speak about what they did previous day, which impediments they faced and what they are going to do in the current day. To make these meetings shorter it is better that people are standing.
During sprint execution it is common to find out additional tasks necessary to achieve sprint goal; to keep the control over processes during sprint development it could be useful to maintain a current '''Sprint Task List''', a '''Sprint Burndown Chart''', and an '''Impediments List''': these are some artefacts that allow developer to understand where the project is located.

===Sprint Review Meeting===
At the end of every Sprint it is held a Review meeting where the scrum team has to explain to the Product Owner what they did during the previous sprint. Usually this meeting consists in a live demonstration of the working product increment after which Product Owner states which Items can be considered as done.
Items which are declared not done have to return to the Product Backlog to be ranked and reprioritized by the Product Owner with the help of the Scrum master. Last step of this meeting is to convert stakeholders’ feedback to a new Product Log, this task is consigned to both Product Owner and Scrum Master.
The Sprint Review Meeting is the appropriate meeting for external stakeholders (even end users) to attend.

===Sprint Retrospective Meeting===
During this meeting every member of the scrum team inspects his behaviour to identify some impediments that he faced during Sprint. There are mainly three kind of impediments in which developers can be involved:
*people who conduct performance evaluation are an obstacles to transparency of the team;
*human tendency of someone in the team to jump to conclusions and propose actions too quickly;
*geographical distribution of the team can be an impediments, team work better if they are delimited in a small place like a room.<ref name='James'></ref>

After identifying all these impediments Scrum master has the task to eliminate them.

===Backlog Refinement Meeting ===
Especially at the beginning of the project "most of the Product Backlog Items (PBIs) need refinement because they are too large and poorly understood" (''M. James, 2010'')<ref name='James'></ref>. In the Backlog Refinement Meeting, the team gave an estimation of the work left to complete Items in the Product Backlog and provides other technical information to help the Product Owner prioritize them.

==Artefacts==
[[File:Product_Backlog.png|200px|thumb|right|Product Backlog<ref name='James'></ref>]]
===Product Backlog===

It is defined before the project beginning and then upgraded during the Backlog Refinement meeting ; it is made up by the whole group of items which have to be completed during the project in order to realize the final product. Every item is ranked and constantly reprioritized by the Product Owner. It is important that Product Backlog Is visible to the stakeholders.

===Product Backlog Item (PBI)===
An item specifies what has to be done but not how do it. Usually they are written in a User story to be understood also by stakeholders. Every items has a work load of 2-3 days and requires 2-3 people. It represents the basic unit of Product backlog.
[[File:Sprint_Backlog.png|200px|thumb|right|Sprint Backlog<ref name='James'></ref>]]
===Sprint backlog===

It is defined at the beginning of each sprint during the Sprint Planning meeting where committed items and the main task that have to be done during the sprint are identified. It has to be visible to Scrum team and it can be upgraded during the sprint execution with additional task necessary to achieve the final goal.

===Sprint task===
Every item is divided into several tasks, each of them requires one day or less of work. A sprint task specifies how to achieve what is required by PBI. If the task takes more than one day of work, remaining effort is re-estimated daily, typically in hours.

===Sprint Burndown Chart===
[[File:Sprint_burndown_chart.png|300px|thumb|right|Sprint Burndown Chart<ref name='James'></ref>]]
This tool is used to facilitate self-organization of the team. It indicates the total remaining team task hours within one Sprint. Usually chart shows a decreasing line but if there are some re-estimation it may be possible that line increase for then going down. As picture shows it has a time line in the x axis and the remaining hours of work within one Sprint in the y axis. The advantage of this tool is to show at a first sight at which point of the project you are and the work that is left to complete the Sprint. It is important that this tool is used only as help to Scrum team; in some situations it could become a constraint for developers, in this case Scrum Master has to remove this chart from the room.

=Limitations=
Scrum method was often used in the object-oriented software development. Actually this technique are applied not only on software but also on other products from different sectors like wheelchairs, semiconductors and mortgages.
Scrum has to be used in those projects where people cannot rely on the plan-driven approaches like Waterfall, because of unknown requirements and technology.
[[File:Graph.png|300px|thumb|right|Predictability of a Project<ref name='James'></ref>]]
Conversely if the projects is placed under precise and stable conditions it is better to use one of the traditional model which allow to have a fixed planning over the whole project. In this case Scrum method would involve in a waste of resources and money because he is working on a field that is not its responsibility.

Michael James in his “Scrum Reference card” explains with a simple graphics in which conditions Scrum should be used and which ones are not. James defines the predictability of the projects on the base of two features: knowledge of the requirements and knowledge of the level of technology required. A project which provides known requirements and a known level of technology should be carried out with a plan-driven model. It these conditions are not met it is better to use an empirical approach like Scrum.<ref name='James'></ref>

=References=
<references/>

Scrum Methodology in Agile Software Development

2015-09-27T10:24:43Z

S150821:

Today market is affected by uncertainly and sudden changes, in these conditions most of the models used in the 20th century to develop software are not still appropriate.[[Wikipedia:Waterfall model | Waterfall model]] , probably the most famous between them, is characterized by a stiff structure which can’t cope with the turbulent needs of actual market.
In recent years many innovations are been enhanced in software engineering with a particular focus on the flexibility of these methods in order to cope with the customer’s and market’s needs; surely '''Agile Software Development''' is between them.

ASD embraces the principles of lean production by applying them in software development to avoid waste and increase responsiveness to change. It represents the solution to the unpredictability of the market where the capacity "to welcome change even late in development" (''K. Beck et all, 2001'')<ref name='Manifesto'></ref> to satisfy customers is required.
This article deals with Agile Software Development with a particular focus on one of its most used technique : '''Scrum Methodology'''.

=Scrum Methodology=
Scrum is an iterative method used to develop software, it can be placed inside the group of methods which are used in '''Agile Software Development'''. This word is taken from rugby and represents that phase of the match where an ordered formation of players, with arms interlocked and heads down, push forward against a similar group to gain possession of the ball. This method provides that "work is divided into small chunks to manage complexity and to get early feedback from customers and end users" (''S. Augustine, 2005'')<ref>S. Augustine,2005,Prentice Hall PTR,Managing Agile Projects</ref>; software development is carried out by small working team that allow rapid adjustment during the process and a quick delivery of the final product.

==Agile Software Development==
Some practitioners believed that traditional [[Wikipedia:Iterative model |Iterative model]] was not so responsive to changes that market required. They thought that to be Agile a process needs to accept change rather than stress predictability and that methods used to develop software has to respond to change as quickly as it arose rather than prevent changes.<ref name='Cohen'>D.Cohen,M.Lindval,P. Costa,Fraunhofer Center Maryland, Agile Software Development</ref>

It was in these circumstances that practitioners as Mary Poppendieck and Bob Charet started to take inspiration from Lean manufacturing principles and apply them to software development.
These are the main points ,according to Poppendieck, which make Lean Production so successful and that can be applied to software development:

*elimination of waste that does not add value to the customer such as diagram and models that do not add value to the final deliverable;
*minimize inventory such as requirements and design documents;
*maximize flow by using iterative development to reduce development time;
*pull from demand;
*empower workers that means “tell developer what needs to be done not how to do it";
*meet customer requirements – work closely with the customer, allowing them to change their minds
*do it right the first time – test early and refactor when necessary;
*abolish local optimization – flexibly manage scope;
*partner with suppliers – avoid adversarial relationships, work towards developing the best software;
*create a culture of continuous improvement – allow the process to improve, learn from mistakes and successes.<ref name='Cohen'></ref><ref>M. Poppendieck, T. Poppendieck, 2003, Addison Wesley, Lean Software Development: An Agile Toolkit[[http://www.poppendieck.com/]]</ref>

===Manifesto for the Agile Software development===
A few years before Poppoendieck’s publication on February 2001 main principles of Agile Software development were stated by a group of 17 software developers which published “Manifesto for the Agile Software Development”.<ref name='Manifesto'>K. Beck et all., 2001, Manifesto for Agile Software Development[http://www.agilemanifesto.org/]</ref>

From reading these few words it is possible to identify what are the main innovations that ASD introduced in Software development:
[[File:Agilemanifesto.jpg|400px|thumb|right|Manifesto for the Agile Software development<ref name='Manifesto'></ref>]]

*'''“Individuals and interactions”''' : with these words founders want to remark the power of human being creativity, and his ability to collaborate with other similar. The stiffness of Waterfall model is instead represented by “processes and tools” where people has to follow only what the plan requires.
*'''“Working software “''' : there is a clear reference to the new way to develop software where at every iteration a working program is realised, differently from the earlier model in which a working program couldn’t be seen until the end of the project. This feature is put over the “comprehensive documentation” which characterizes especially Waterfall model.
*'''“Customer collaboration”''' : means that there must be a straight relationship between customer and developer in order to define time by time the projects requirements and evaluate every realise.
*'''“Responding to change over following a plan”''' : this sentence encloses the essence of Agile software Development that is to cope with turbulent markets by being flexible and by responding quickly to change, instead of being bound by planning. This concept is remarked by the founders in one of the twelve principles which follow the manifesto which says “Welcome changing requirements, even late in development […]”.

=Application=
[[File:Scrum_Framework.png|350px|thumb|right|Scrum Framework]]
There are two concepts that are at the basement of Scrum methodology: '''iterative development''' and '''team working'''. Developing in iterations allow Scrum team to adapt quickly to changing requirements, while working in close location and focusing on communication allow team to make decisions and act on them immediately rather than wait on correspondence.<ref name='Cohen'></ref>

Basically Scrum consists in a sequence of fixed-length iterations called [[Sprint:http://apppm.man.dtu.dk/index.php?title=Scrum_Methodology_in_Agile_Software_Development&action=submit#Sprint|Sprint]] managed by one or more '''cross-functional and self-organizing teams''' each composed by seven people that aim at a common goal and that usually work only on the software development. There are instead other two figures that manage all things that are in support of the development process: one is '''Product Owner''' who mainly handles customers contacts and the other is '''Scrum Master''' whose main task is to ensure that development team can work without obstacles.

Each sprint usually lasts from 2 to 4 weeks, in this period there are at least one meeting between the Product Owner and Development Team to define the main objectives; then there are short daily meetings held every morning to enhance communication and inform customers, developers, and managers on the status of the project, identify any problems encountered, and keep the entire team focused on a common goal.<ref name='Cohen'></ref>

==Main figures in Scrum==
===Product Owner===
Product owner is the link between customers and development team, he ensures that deliverables are in line with customers’ expectation and that stakeholders’ interests are fulfilled. He has also the task to fill out customer-centric items (typically '''user stories'''), ranks and prioritizes them before adds them to '''Product Backlog'''.

Usually development teams have only one Product owner, but differently from the Scrum master, he only takes care of the business side and does not interfere with the scrum team about the technological issues. At the beginning of each Sprint the Product Owner holds a Sprint Planning Meeting to state on which Product Backlog Items Scrum team will go to work during the next Sprint. In this phase he defines what are the most important items for that business, in according to customer’s needs.

===Development Team===
Development team task is to provide Product Backlog Items (PBIs) at the end of every Sprint in according with customers’ requirements after negotiating commitments with the Product Owner.
Usually each team is composed by '''cross-functional members''' that allow an all-round software development; the main figures that there must be are a mix of software engineers, architects, programmers, analysts, QA experts, testers, and UI designers.

The size of the team is an important point, the group members' number influences capacity of people to communicate and work together: it is recommended that a scrum team is composed not more than nine people, usually seven.

Another important characteristic is the Self-organization of the group which facilitates members’ creativity and increases team cohesiveness: for this reason it is better to not change members of a team after they have worked together, especially if they had success in their project. After working together team members gain a mutual understanding that increases their capacity of team working, this synergy cannot be acquired if team are continuously changed.

A further point that characterized the good outcomes of a scrum team is location: people are most successful when located in the same room, particularly for the first few Sprints: this facilitates communication and information sharing.

====Team self-organization====
Team self-organization is a crucial point in the scrum methodology : with this concept it means that “it is told developer what needs to be done not how to do it”, they can autonomously choose the way to reach commitments.
As it is said previously during Sprint execution, team members develop an intrinsic interest in shared goals and learn to manage each other to achieve them, for this reason self-organizing teams can radically outperform larger than traditionally managed teams. It has to be specified that an optimal self-organization takes time: it may be possible that for the first few sprints developers perform worse than when they work in the traditional way.

Some requirements are necessary to gain a good team self-organization:
*members are committed to clear, short-term goals;
*members can gauge the group’s progress;
*members can observe each other’s contribution;
*members feel safe to give each other unvarnished feedback.<ref name='James'>M. James,2010,Scrum Reference Card, Michael James,[[http://scrumreferencecard.com/]]</ref>

Conversely there are some conditions that can hander self-organization:
*geographical distribution: it is better if the whole team work in a room;
*boss/work dynamics: each member has to consider the others as peer to facilitate a fair communication between them;
*part-time team members;
*interruptions unrelated to Sprint goals.

===Scrum Master===
The scrum master worries that Scrum team can work without obstacles but he has no management authority over them. Essentially he has the aim to:
*create an environment to promote team self-organization;
*support team in the achievement of expected goals;
*ensure that events (e.g. daily Scrum meeting) take place in the right way;
*keep '''Scrum artefacts''' visible ('''Product Backlog''', '''Sprint Backlog''', '''Sprint burndown chart''' …).

==Sprint==
Sprint (or iteration) is the fundamental unit in which the work is divided; it is characterized by a fixed length of 2 weeks or 30 days and by a goal to achieve. At the beginning of each sprint Scrum team , Product Owner , Scrum Master and sometimes also stakeholders hold a meeting, called Sprint Planning meeting whose output is the Sprint Backlog where goals and requirements of the next Sprint are defined. Then other meetings inside development team will be held in order to define in more detail how achieving the common goals stated in the previous meeting.
==Scrum Meetings==
[[File:Scrum_meetings.png|350px|thumb|right|Scrum Meetings<ref name='James'></ref>]]
Meeting are a fundamental tool used during the whole Scrum process. Usually they are facilitated by the Scrum master who has no decision-making authority over them . There are different typologies of meetings according to the different phase of the process in which we are.
===Sprint Planning Meeting===
At the beginning of each Sprint, the Product Owner and team hold a Sprint Planning Meeting to define on which '''Product Backlog Items (PBIs)''' they will go to work during the next Sprint. "The Product Owner is responsible for declaring which items are the most important to the business. The team is responsible for selecting the amount of work they feel they can implement" (''M. James, 2010'')<ref name='James'></ref>.In this phase in perfect Lean perspective the team “pulls” work from the Product Backlog to the Sprint Backlog. At the end of the meeting the selected items are broken into a provisional list of Sprint task. The maximum time that can be used to do Planning meeting, known as '''timebox''', is of eight hours.

===Daily Scrum and Sprint Execution===
During the sprint every day members of the Scrum team hold a fifteen minutes meeting where they take stock of the situation. Usually they speak about what they did previous day, which impediments they faced and what they are going to do in the current day. To make these meetings shorter it is better that people are standing.
During sprint execution it is common to find out additional tasks necessary to achieve sprint goal; to keep the control over processes during sprint development it could be useful to maintain a current '''Sprint Task List''', a '''Sprint Burndown Chart''', and an '''Impediments List''': these are some artefacts that allow developer to understand where the project is located.

===Sprint Review Meeting===
At the end of every Sprint it is held a Review meeting where the scrum team has to explain to the Product Owner what they did during the previous sprint. Usually this meeting consists in a live demonstration of the working product increment after which Product Owner states which Items can be considered as done.
Items which are declared not done have to return to the Product Backlog to be ranked and reprioritized by the Product Owner with the help of the Scrum master. Last step of this meeting is to convert stakeholders’ feedback to a new Product Log, this task is consigned to both Product Owner and Scrum Master.
The Sprint Review Meeting is the appropriate meeting for external stakeholders (even end users) to attend.

===Sprint Retrospective Meeting===
During this meeting every member of the scrum team inspects his behaviour to identify some impediments that he faced during Sprint. There are mainly three kind of impediments in which developers can be involved:
*people who conduct performance evaluation are an obstacles to transparency of the team;
*human tendency of someone in the team to jump to conclusions and propose actions too quickly;
*geographical distribution of the team can be an impediments, team work better if they are delimited in a small place like a room.<ref name='James'></ref>

After identifying all these impediments Scrum master has the task to eliminate them.

===Backlog Refinement Meeting ===
Especially at the beginning of the project "most of the Product Backlog Items (PBIs) need refinement because they are too large and poorly understood" (''M. James, 2010'')<ref name='James'></ref>. In the Backlog Refinement Meeting, the team gave an estimation of the work left to complete Items in the Product Backlog and provides other technical information to help the Product Owner prioritize them.

==Artefacts==
[[File:Product_Backlog.png|200px|thumb|right|Product Backlog<ref name='James'></ref>]]
===Product Backlog===

It is defined before the project beginning and then upgraded during the Backlog Refinement meeting ; it is made up by the whole group of items which have to be completed during the project in order to realize the final product. Every item is ranked and constantly reprioritized by the Product Owner. It is important that Product Backlog Is visible to the stakeholders.

===Product Backlog Item (PBI)===
An item specifies what has to be done but not how do it. Usually they are written in a User story to be understood also by stakeholders. Every items has a work load of 2-3 days and requires 2-3 people. It represents the basic unit of Product backlog.
[[File:Sprint_Backlog.png|200px|thumb|right|Sprint Backlog<ref name='James'></ref>]]
===Sprint backlog===

It is defined at the beginning of each sprint during the Sprint Planning meeting where committed items and the main task that have to be done during the sprint are identified. It has to be visible to Scrum team and it can be upgraded during the sprint execution with additional task necessary to achieve the final goal.

===Sprint task===
Every item is divided into several tasks, each of them requires one day or less of work. A sprint task specifies how to achieve what is required by PBI. If the task takes more than one day of work, remaining effort is re-estimated daily, typically in hours.

===Sprint Burndown Chart===
[[File:Sprint_burndown_chart.png|300px|thumb|right|Sprint Burndown Chart<ref name='James'></ref>]]
This tool is used to facilitate self-organization of the team. It indicates the total remaining team task hours within one Sprint. Usually chart shows a decreasing line but if there are some re-estimation it may be possible that line increase for then going down. As picture shows it has a time line in the x axis and the remaining hours of work within one Sprint in the y axis. The advantage of this tool is to show at a first sight at which point of the project you are and the work that is left to complete the Sprint. It is important that this tool is used only as help to Scrum team; in some situations it could become a constraint for developers, in this case Scrum Master has to remove this chart from the room.

=Limitations=
Scrum method was often used in the object-oriented software development. Actually this technique are applied not only on software but also on other products from different sectors like wheelchairs, semiconductors and mortgages.
Scrum has to be used in those projects where people cannot rely on the plan-driven approaches like Waterfall, because of unknown requirements and technology.
[[File:Graph.png|300px|thumb|right|Predictability of a Project<ref name='James'></ref>]]
Conversely if the projects is placed under precise and stable conditions it is better to use one of the traditional model which allow to have a fixed planning over the whole project. In this case Scrum method would involve in a waste of resources and money because he is working on a field that is not its responsibility.

Michael James in his “Scrum Reference card” explains with a simple graphics in which conditions Scrum should be used and which ones are not. James defines the predictability of the projects on the base of two features: knowledge of the requirements and knowledge of the level of technology required. A project which provides known requirements and a known level of technology should be carried out with a plan-driven model. It these conditions are not met it is better to use an empirical approach like Scrum.<ref name='James'></ref>

=References=
<references/>

Scrum Methodology in Agile Software Development

2015-09-27T10:21:12Z

S150821: /* Limitations */

Today market is affected by uncertainly and sudden changes, in these conditions most of the models used in the 20th century to develop software are not still appropriate. Waterfall model , probably the most famous between them, is characterized by a stiff structure which can’t cope with the turbulent needs of actual market.
In recent years many innovations are been enhanced in software engineering with a particular focus on the flexibility of these methods in order to cope with the customer’s and market’s needs; surely '''Agile Software Development''' is between them.

ASD embraces the principles of lean production by applying them in software development to avoid waste and increase responsiveness to change. It represents the solution to the unpredictability of the market where the capacity "to welcome change even late in development" (''K. Beck et all, 2001'')<ref name='Manifesto'></ref> to satisfy customers is required.
This article deals with Agile Software Development with a particular focus on one of its most used technique : '''Scrum Methodology'''.

=Scrum Methodology=
Scrum is an iterative method used to develop software, it can be placed inside the group of methods which are used in '''Agile Software Development'''. This word is taken from rugby and represents that phase of the match where an ordered formation of players, with arms interlocked and heads down, push forward against a similar group to gain possession of the ball. This method provides that "work is divided into small chunks to manage complexity and to get early feedback from customers and end users" (''S. Augustine, 2005'')<ref>S. Augustine,2005,Prentice Hall PTR,Managing Agile Projects</ref>; software development is carried out by small working team that allow rapid adjustment during the process and a quick delivery of the final product.

==Agile Software Development==
Some practitioners believed that traditional iterative model was not so responsive to changes that market required. They thought that to be Agile a process needs to accept change rather than stress predictability and that methods used to develop software has to respond to change as quickly as it arose rather than prevent changes.<ref name='Cohen'>D.Cohen,M.Lindval,P. Costa,Fraunhofer Center Maryland, Agile Software Development</ref>

It was in these circumstances that practitioners as Mary Poppendieck and Bob Charet started to take inspiration from Lean manufacturing principles and apply them to software development.
These are the main points ,according to Poppendieck, which make Lean Production so successful and that can be applied to software development:

*elimination of waste that does not add value to the customer such as diagram and models that do not add value to the final deliverable;
*minimize inventory such as requirements and design documents;
*maximize flow by using iterative development to reduce development time;
*pull from demand;
*empower workers that means “tell developer what needs to be done not how to do it";
*meet customer requirements – work closely with the customer, allowing them to change their minds
*do it right the first time – test early and refactor when necessary;
*abolish local optimization – flexibly manage scope;
*partner with suppliers – avoid adversarial relationships, work towards developing the best software;
*create a culture of continuous improvement – allow the process to improve, learn from mistakes and successes.<ref name='Cohen'></ref><ref>M. Poppendieck, T. Poppendieck, 2003, Addison Wesley, Lean Software Development: An Agile Toolkit[[http://www.poppendieck.com/]]</ref>

===Manifesto for the Agile Software development===
A few years before Poppoendieck’s publication on February 2001 main principles of Agile Software development were stated by a group of 17 software developers which published “Manifesto for the Agile Software Development”.<ref name='Manifesto'>K. Beck et all., 2001, Manifesto for Agile Software Development[http://www.agilemanifesto.org/]</ref>

From reading these few words it is possible to identify what are the main innovations that ASD introduced in Software development:
[[File:Agilemanifesto.jpg|400px|thumb|right|Manifesto for the Agile Software development<ref name='Manifesto'></ref>]]

*'''“Individuals and interactions”''' : with these words founders want to remark the power of human being creativity, and his ability to collaborate with other similar. The stiffness of Waterfall model is instead represented by “processes and tools” where people has to follow only what the plan requires.
*'''“Working software “''' : there is a clear reference to the new way to develop software where at every iteration a working program is realised, differently from the earlier model in which a working program couldn’t be seen until the end of the project. This feature is put over the “comprehensive documentation” which characterizes especially Waterfall model.
*'''“Customer collaboration”''' : means that there must be a straight relationship between customer and developer in order to define time by time the projects requirements and evaluate every realise.
*'''“Responding to change over following a plan”''' : this sentence encloses the essence of Agile software Development that is to cope with turbulent markets by being flexible and by responding quickly to change, instead of being bound by planning. This concept is remarked by the founders in one of the twelve principles which follow the manifesto which says “Welcome changing requirements, even late in development […]”.

=Application=
[[File:Scrum_Framework.png|350px|thumb|right|Scrum Framework]]
There are two concepts that are at the basement of Scrum methodology: '''iterative development''' and '''team working'''. Developing in iterations allow Scrum team to adapt quickly to changing requirements, while working in close location and focusing on communication allow team to make decisions and act on them immediately rather than wait on correspondence.<ref name='Cohen'></ref>

Basically Scrum consists in a sequence of fixed-length iterations called [[Sprint:http://apppm.man.dtu.dk/index.php?title=Scrum_Methodology_in_Agile_Software_Development&action=submit#Sprint|Sprint]] managed by one or more '''cross-functional and self-organizing teams''' each composed by seven people that aim at a common goal and that usually work only on the software development. There are instead other two figures that manage all things that are in support of the development process: one is '''Product Owner''' who mainly handles customers contacts and the other is '''Scrum Master''' whose main task is to ensure that development team can work without obstacles.

Each sprint usually lasts from 2 to 4 weeks, in this period there are at least one meeting between the Product Owner and Development Team to define the main objectives; then there are short daily meetings held every morning to enhance communication and inform customers, developers, and managers on the status of the project, identify any problems encountered, and keep the entire team focused on a common goal.<ref name='Cohen'></ref>

==Main figures in Scrum==
===Product Owner===
Product owner is the link between customers and development team, he ensures that deliverables are in line with customers’ expectation and that stakeholders’ interests are fulfilled. He has also the task to fill out customer-centric items (typically '''user stories'''), ranks and prioritizes them before adds them to '''Product Backlog'''.

Usually development teams have only one Product owner, but differently from the Scrum master, he only takes care of the business side and does not interfere with the scrum team about the technological issues. At the beginning of each Sprint the Product Owner holds a Sprint Planning Meeting to state on which Product Backlog Items Scrum team will go to work during the next Sprint. In this phase he defines what are the most important items for that business, in according to customer’s needs.

===Development Team===
Development team task is to provide Product Backlog Items (PBIs) at the end of every Sprint in according with customers’ requirements after negotiating commitments with the Product Owner.
Usually each team is composed by '''cross-functional members''' that allow an all-round software development; the main figures that there must be are a mix of software engineers, architects, programmers, analysts, QA experts, testers, and UI designers.

The size of the team is an important point, the group members' number influences capacity of people to communicate and work together: it is recommended that a scrum team is composed not more than nine people, usually seven.

Another important characteristic is the Self-organization of the group which facilitates members’ creativity and increases team cohesiveness: for this reason it is better to not change members of a team after they have worked together, especially if they had success in their project. After working together team members gain a mutual understanding that increases their capacity of team working, this synergy cannot be acquired if team are continuously changed.

A further point that characterized the good outcomes of a scrum team is location: people are most successful when located in the same room, particularly for the first few Sprints: this facilitates communication and information sharing.

====Team self-organization====
Team self-organization is a crucial point in the scrum methodology : with this concept it means that “it is told developer what needs to be done not how to do it”, they can autonomously choose the way to reach commitments.
As it is said previously during Sprint execution, team members develop an intrinsic interest in shared goals and learn to manage each other to achieve them, for this reason self-organizing teams can radically outperform larger than traditionally managed teams. It has to be specified that an optimal self-organization takes time: it may be possible that for the first few sprints developers perform worse than when they work in the traditional way.

Some requirements are necessary to gain a good team self-organization:
*members are committed to clear, short-term goals;
*members can gauge the group’s progress;
*members can observe each other’s contribution;
*members feel safe to give each other unvarnished feedback.<ref name='James'>M. James,2010,Scrum Reference Card, Michael James,[[http://scrumreferencecard.com/]]</ref>

Conversely there are some conditions that can hander self-organization:
*geographical distribution: it is better if the whole team work in a room;
*boss/work dynamics: each member has to consider the others as peer to facilitate a fair communication between them;
*part-time team members;
*interruptions unrelated to Sprint goals.

===Scrum Master===
The scrum master worries that Scrum team can work without obstacles but he has no management authority over them. Essentially he has the aim to:
*create an environment to promote team self-organization;
*support team in the achievement of expected goals;
*ensure that events (e.g. daily Scrum meeting) take place in the right way;
*keep '''Scrum artefacts''' visible ('''Product Backlog''', '''Sprint Backlog''', '''Sprint burndown chart''' …).

==Sprint==
Sprint (or iteration) is the fundamental unit in which the work is divided; it is characterized by a fixed length of 2 weeks or 30 days and by a goal to achieve. At the beginning of each sprint Scrum team , Product Owner , Scrum Master and sometimes also stakeholders hold a meeting, called Sprint Planning meeting whose output is the Sprint Backlog where goals and requirements of the next Sprint are defined. Then other meetings inside development team will be held in order to define in more detail how achieving the common goals stated in the previous meeting.
==Scrum Meetings==
[[File:Scrum_meetings.png|350px|thumb|right|Scrum Meetings<ref name='James'></ref>]]
Meeting are a fundamental tool used during the whole Scrum process. Usually they are facilitated by the Scrum master who has no decision-making authority over them . There are different typologies of meetings according to the different phase of the process in which we are.
===Sprint Planning Meeting===
At the beginning of each Sprint, the Product Owner and team hold a Sprint Planning Meeting to define on which '''Product Backlog Items (PBIs)''' they will go to work during the next Sprint. "The Product Owner is responsible for declaring which items are the most important to the business. The team is responsible for selecting the amount of work they feel they can implement" (''M. James, 2010'')<ref name='James'></ref>.In this phase in perfect Lean perspective the team “pulls” work from the Product Backlog to the Sprint Backlog. At the end of the meeting the selected items are broken into a provisional list of Sprint task. The maximum time that can be used to do Planning meeting, known as '''timebox''', is of eight hours.

===Daily Scrum and Sprint Execution===
During the sprint every day members of the Scrum team hold a fifteen minutes meeting where they take stock of the situation. Usually they speak about what they did previous day, which impediments they faced and what they are going to do in the current day. To make these meetings shorter it is better that people are standing.
During sprint execution it is common to find out additional tasks necessary to achieve sprint goal; to keep the control over processes during sprint development it could be useful to maintain a current '''Sprint Task List''', a '''Sprint Burndown Chart''', and an '''Impediments List''': these are some artefacts that allow developer to understand where the project is located.

===Sprint Review Meeting===
At the end of every Sprint it is held a Review meeting where the scrum team has to explain to the Product Owner what they did during the previous sprint. Usually this meeting consists in a live demonstration of the working product increment after which Product Owner states which Items can be considered as done.
Items which are declared not done have to return to the Product Backlog to be ranked and reprioritized by the Product Owner with the help of the Scrum master. Last step of this meeting is to convert stakeholders’ feedback to a new Product Log, this task is consigned to both Product Owner and Scrum Master.
The Sprint Review Meeting is the appropriate meeting for external stakeholders (even end users) to attend.

===Sprint Retrospective Meeting===
During this meeting every member of the scrum team inspects his behaviour to identify some impediments that he faced during Sprint. There are mainly three kind of impediments in which developers can be involved:
*people who conduct performance evaluation are an obstacles to transparency of the team;
*human tendency of someone in the team to jump to conclusions and propose actions too quickly;
*geographical distribution of the team can be an impediments, team work better if they are delimited in a small place like a room.<ref name='James'></ref>

After identifying all these impediments Scrum master has the task to eliminate them.

===Backlog Refinement Meeting ===
Especially at the beginning of the project "most of the Product Backlog Items (PBIs) need refinement because they are too large and poorly understood" (''M. James, 2010'')<ref name='James'></ref>. In the Backlog Refinement Meeting, the team gave an estimation of the work left to complete Items in the Product Backlog and provides other technical information to help the Product Owner prioritize them.

==Artefacts==
[[File:Product_Backlog.png|200px|thumb|right|Product Backlog<ref name='James'></ref>]]
===Product Backlog===

It is defined before the project beginning and then upgraded during the Backlog Refinement meeting ; it is made up by the whole group of items which have to be completed during the project in order to realize the final product. Every item is ranked and constantly reprioritized by the Product Owner. It is important that Product Backlog Is visible to the stakeholders.

===Product Backlog Item (PBI)===
An item specifies what has to be done but not how do it. Usually they are written in a User story to be understood also by stakeholders. Every items has a work load of 2-3 days and requires 2-3 people. It represents the basic unit of Product backlog.
[[File:Sprint_Backlog.png|200px|thumb|right|Sprint Backlog<ref name='James'></ref>]]
===Sprint backlog===

It is defined at the beginning of each sprint during the Sprint Planning meeting where committed items and the main task that have to be done during the sprint are identified. It has to be visible to Scrum team and it can be upgraded during the sprint execution with additional task necessary to achieve the final goal.

===Sprint task===
Every item is divided into several tasks, each of them requires one day or less of work. A sprint task specifies how to achieve what is required by PBI. If the task takes more than one day of work, remaining effort is re-estimated daily, typically in hours.

===Sprint Burndown Chart===
[[File:Sprint_burndown_chart.png|300px|thumb|right|Sprint Burndown Chart<ref name='James'></ref>]]
This tool is used to facilitate self-organization of the team. It indicates the total remaining team task hours within one Sprint. Usually chart shows a decreasing line but if there are some re-estimation it may be possible that line increase for then going down. As picture shows it has a time line in the x axis and the remaining hours of work within one Sprint in the y axis. The advantage of this tool is to show at a first sight at which point of the project you are and the work that is left to complete the Sprint. It is important that this tool is used only as help to Scrum team; in some situations it could become a constraint for developers, in this case Scrum Master has to remove this chart from the room.

=Limitations=
Scrum method was often used in the object-oriented software development. Actually this technique are applied not only on software but also on other products from different sectors like wheelchairs, semiconductors and mortgages.
Scrum has to be used in those projects where people cannot rely on the plan-driven approaches like Waterfall, because of unknown requirements and technology.
[[File:Graph.png|300px|thumb|right|Predictability of a Project<ref name='James'></ref>]]
Conversely if the projects is placed under precise and stable conditions it is better to use one of the traditional model which allow to have a fixed planning over the whole project. In this case Scrum method would involve in a waste of resources and money because he is working on a field that is not its responsibility.

Michael James in his “Scrum Reference card” explains with a simple graphics in which conditions Scrum should be used and which ones are not. James defines the predictability of the projects on the base of two features: knowledge of the requirements and knowledge of the level of technology required. A project which provides known requirements and a known level of technology should be carried out with a plan-driven model. It these conditions are not met it is better to use an empirical approach like Scrum.<ref name='James'></ref>

=References=
<references/>

Scrum Methodology in Agile Software Development

2015-09-27T10:16:14Z

S150821: /* Sprint Burndown Chart */

Today market is affected by uncertainly and sudden changes, in these conditions most of the models used in the 20th century to develop software are not still appropriate. Waterfall model , probably the most famous between them, is characterized by a stiff structure which can’t cope with the turbulent needs of actual market.
In recent years many innovations are been enhanced in software engineering with a particular focus on the flexibility of these methods in order to cope with the customer’s and market’s needs; surely '''Agile Software Development''' is between them.

ASD embraces the principles of lean production by applying them in software development to avoid waste and increase responsiveness to change. It represents the solution to the unpredictability of the market where the capacity "to welcome change even late in development" (''K. Beck et all, 2001'')<ref name='Manifesto'></ref> to satisfy customers is required.
This article deals with Agile Software Development with a particular focus on one of its most used technique : '''Scrum Methodology'''.

=Scrum Methodology=
Scrum is an iterative method used to develop software, it can be placed inside the group of methods which are used in '''Agile Software Development'''. This word is taken from rugby and represents that phase of the match where an ordered formation of players, with arms interlocked and heads down, push forward against a similar group to gain possession of the ball. This method provides that "work is divided into small chunks to manage complexity and to get early feedback from customers and end users" (''S. Augustine, 2005'')<ref>S. Augustine,2005,Prentice Hall PTR,Managing Agile Projects</ref>; software development is carried out by small working team that allow rapid adjustment during the process and a quick delivery of the final product.

==Agile Software Development==
Some practitioners believed that traditional iterative model was not so responsive to changes that market required. They thought that to be Agile a process needs to accept change rather than stress predictability and that methods used to develop software has to respond to change as quickly as it arose rather than prevent changes.<ref name='Cohen'>D.Cohen,M.Lindval,P. Costa,Fraunhofer Center Maryland, Agile Software Development</ref>

It was in these circumstances that practitioners as Mary Poppendieck and Bob Charet started to take inspiration from Lean manufacturing principles and apply them to software development.
These are the main points ,according to Poppendieck, which make Lean Production so successful and that can be applied to software development:

*elimination of waste that does not add value to the customer such as diagram and models that do not add value to the final deliverable;
*minimize inventory such as requirements and design documents;
*maximize flow by using iterative development to reduce development time;
*pull from demand;
*empower workers that means “tell developer what needs to be done not how to do it";
*meet customer requirements – work closely with the customer, allowing them to change their minds
*do it right the first time – test early and refactor when necessary;
*abolish local optimization – flexibly manage scope;
*partner with suppliers – avoid adversarial relationships, work towards developing the best software;
*create a culture of continuous improvement – allow the process to improve, learn from mistakes and successes.<ref name='Cohen'></ref><ref>M. Poppendieck, T. Poppendieck, 2003, Addison Wesley, Lean Software Development: An Agile Toolkit[[http://www.poppendieck.com/]]</ref>

===Manifesto for the Agile Software development===
A few years before Poppoendieck’s publication on February 2001 main principles of Agile Software development were stated by a group of 17 software developers which published “Manifesto for the Agile Software Development”.<ref name='Manifesto'>K. Beck et all., 2001, Manifesto for Agile Software Development[http://www.agilemanifesto.org/]</ref>

From reading these few words it is possible to identify what are the main innovations that ASD introduced in Software development:
[[File:Agilemanifesto.jpg|400px|thumb|right|Manifesto for the Agile Software development<ref name='Manifesto'></ref>]]

*'''“Individuals and interactions”''' : with these words founders want to remark the power of human being creativity, and his ability to collaborate with other similar. The stiffness of Waterfall model is instead represented by “processes and tools” where people has to follow only what the plan requires.
*'''“Working software “''' : there is a clear reference to the new way to develop software where at every iteration a working program is realised, differently from the earlier model in which a working program couldn’t be seen until the end of the project. This feature is put over the “comprehensive documentation” which characterizes especially Waterfall model.
*'''“Customer collaboration”''' : means that there must be a straight relationship between customer and developer in order to define time by time the projects requirements and evaluate every realise.
*'''“Responding to change over following a plan”''' : this sentence encloses the essence of Agile software Development that is to cope with turbulent markets by being flexible and by responding quickly to change, instead of being bound by planning. This concept is remarked by the founders in one of the twelve principles which follow the manifesto which says “Welcome changing requirements, even late in development […]”.

=Application=
[[File:Scrum_Framework.png|350px|thumb|right|Scrum Framework]]
There are two concepts that are at the basement of Scrum methodology: '''iterative development''' and '''team working'''. Developing in iterations allow Scrum team to adapt quickly to changing requirements, while working in close location and focusing on communication allow team to make decisions and act on them immediately rather than wait on correspondence.<ref name='Cohen'></ref>

Basically Scrum consists in a sequence of fixed-length iterations called [[Sprint:http://apppm.man.dtu.dk/index.php?title=Scrum_Methodology_in_Agile_Software_Development&action=submit#Sprint|Sprint]] managed by one or more '''cross-functional and self-organizing teams''' each composed by seven people that aim at a common goal and that usually work only on the software development. There are instead other two figures that manage all things that are in support of the development process: one is '''Product Owner''' who mainly handles customers contacts and the other is '''Scrum Master''' whose main task is to ensure that development team can work without obstacles.

Each sprint usually lasts from 2 to 4 weeks, in this period there are at least one meeting between the Product Owner and Development Team to define the main objectives; then there are short daily meetings held every morning to enhance communication and inform customers, developers, and managers on the status of the project, identify any problems encountered, and keep the entire team focused on a common goal.<ref name='Cohen'></ref>

==Main figures in Scrum==
===Product Owner===
Product owner is the link between customers and development team, he ensures that deliverables are in line with customers’ expectation and that stakeholders’ interests are fulfilled. He has also the task to fill out customer-centric items (typically '''user stories'''), ranks and prioritizes them before adds them to '''Product Backlog'''.

Usually development teams have only one Product owner, but differently from the Scrum master, he only takes care of the business side and does not interfere with the scrum team about the technological issues. At the beginning of each Sprint the Product Owner holds a Sprint Planning Meeting to state on which Product Backlog Items Scrum team will go to work during the next Sprint. In this phase he defines what are the most important items for that business, in according to customer’s needs.

===Development Team===
Development team task is to provide Product Backlog Items (PBIs) at the end of every Sprint in according with customers’ requirements after negotiating commitments with the Product Owner.
Usually each team is composed by '''cross-functional members''' that allow an all-round software development; the main figures that there must be are a mix of software engineers, architects, programmers, analysts, QA experts, testers, and UI designers.

The size of the team is an important point, the group members' number influences capacity of people to communicate and work together: it is recommended that a scrum team is composed not more than nine people, usually seven.

Another important characteristic is the Self-organization of the group which facilitates members’ creativity and increases team cohesiveness: for this reason it is better to not change members of a team after they have worked together, especially if they had success in their project. After working together team members gain a mutual understanding that increases their capacity of team working, this synergy cannot be acquired if team are continuously changed.

A further point that characterized the good outcomes of a scrum team is location: people are most successful when located in the same room, particularly for the first few Sprints: this facilitates communication and information sharing.

====Team self-organization====
Team self-organization is a crucial point in the scrum methodology : with this concept it means that “it is told developer what needs to be done not how to do it”, they can autonomously choose the way to reach commitments.
As it is said previously during Sprint execution, team members develop an intrinsic interest in shared goals and learn to manage each other to achieve them, for this reason self-organizing teams can radically outperform larger than traditionally managed teams. It has to be specified that an optimal self-organization takes time: it may be possible that for the first few sprints developers perform worse than when they work in the traditional way.

Some requirements are necessary to gain a good team self-organization:
*members are committed to clear, short-term goals;
*members can gauge the group’s progress;
*members can observe each other’s contribution;
*members feel safe to give each other unvarnished feedback.<ref name='James'>M. James,2010,Scrum Reference Card, Michael James,[[http://scrumreferencecard.com/]]</ref>

Conversely there are some conditions that can hander self-organization:
*geographical distribution: it is better if the whole team work in a room;
*boss/work dynamics: each member has to consider the others as peer to facilitate a fair communication between them;
*part-time team members;
*interruptions unrelated to Sprint goals.

===Scrum Master===
The scrum master worries that Scrum team can work without obstacles but he has no management authority over them. Essentially he has the aim to:
*create an environment to promote team self-organization;
*support team in the achievement of expected goals;
*ensure that events (e.g. daily Scrum meeting) take place in the right way;
*keep '''Scrum artefacts''' visible ('''Product Backlog''', '''Sprint Backlog''', '''Sprint burndown chart''' …).

==Sprint==
Sprint (or iteration) is the fundamental unit in which the work is divided; it is characterized by a fixed length of 2 weeks or 30 days and by a goal to achieve. At the beginning of each sprint Scrum team , Product Owner , Scrum Master and sometimes also stakeholders hold a meeting, called Sprint Planning meeting whose output is the Sprint Backlog where goals and requirements of the next Sprint are defined. Then other meetings inside development team will be held in order to define in more detail how achieving the common goals stated in the previous meeting.
==Scrum Meetings==
[[File:Scrum_meetings.png|350px|thumb|right|Scrum Meetings<ref name='James'></ref>]]
Meeting are a fundamental tool used during the whole Scrum process. Usually they are facilitated by the Scrum master who has no decision-making authority over them . There are different typologies of meetings according to the different phase of the process in which we are.
===Sprint Planning Meeting===
At the beginning of each Sprint, the Product Owner and team hold a Sprint Planning Meeting to define on which '''Product Backlog Items (PBIs)''' they will go to work during the next Sprint. "The Product Owner is responsible for declaring which items are the most important to the business. The team is responsible for selecting the amount of work they feel they can implement" (''M. James, 2010'')<ref name='James'></ref>.In this phase in perfect Lean perspective the team “pulls” work from the Product Backlog to the Sprint Backlog. At the end of the meeting the selected items are broken into a provisional list of Sprint task. The maximum time that can be used to do Planning meeting, known as '''timebox''', is of eight hours.

===Daily Scrum and Sprint Execution===
During the sprint every day members of the Scrum team hold a fifteen minutes meeting where they take stock of the situation. Usually they speak about what they did previous day, which impediments they faced and what they are going to do in the current day. To make these meetings shorter it is better that people are standing.
During sprint execution it is common to find out additional tasks necessary to achieve sprint goal; to keep the control over processes during sprint development it could be useful to maintain a current '''Sprint Task List''', a '''Sprint Burndown Chart''', and an '''Impediments List''': these are some artefacts that allow developer to understand where the project is located.

===Sprint Review Meeting===
At the end of every Sprint it is held a Review meeting where the scrum team has to explain to the Product Owner what they did during the previous sprint. Usually this meeting consists in a live demonstration of the working product increment after which Product Owner states which Items can be considered as done.
Items which are declared not done have to return to the Product Backlog to be ranked and reprioritized by the Product Owner with the help of the Scrum master. Last step of this meeting is to convert stakeholders’ feedback to a new Product Log, this task is consigned to both Product Owner and Scrum Master.
The Sprint Review Meeting is the appropriate meeting for external stakeholders (even end users) to attend.

===Sprint Retrospective Meeting===
During this meeting every member of the scrum team inspects his behaviour to identify some impediments that he faced during Sprint. There are mainly three kind of impediments in which developers can be involved:
*people who conduct performance evaluation are an obstacles to transparency of the team;
*human tendency of someone in the team to jump to conclusions and propose actions too quickly;
*geographical distribution of the team can be an impediments, team work better if they are delimited in a small place like a room.<ref name='James'></ref>

After identifying all these impediments Scrum master has the task to eliminate them.

===Backlog Refinement Meeting ===
Especially at the beginning of the project "most of the Product Backlog Items (PBIs) need refinement because they are too large and poorly understood" (''M. James, 2010'')<ref name='James'></ref>. In the Backlog Refinement Meeting, the team gave an estimation of the work left to complete Items in the Product Backlog and provides other technical information to help the Product Owner prioritize them.

==Artefacts==
[[File:Product_Backlog.png|200px|thumb|right|Product Backlog<ref name='James'></ref>]]
===Product Backlog===

It is defined before the project beginning and then upgraded during the Backlog Refinement meeting ; it is made up by the whole group of items which have to be completed during the project in order to realize the final product. Every item is ranked and constantly reprioritized by the Product Owner. It is important that Product Backlog Is visible to the stakeholders.

===Product Backlog Item (PBI)===
An item specifies what has to be done but not how do it. Usually they are written in a User story to be understood also by stakeholders. Every items has a work load of 2-3 days and requires 2-3 people. It represents the basic unit of Product backlog.
[[File:Sprint_Backlog.png|200px|thumb|right|Sprint Backlog<ref name='James'></ref>]]
===Sprint backlog===

It is defined at the beginning of each sprint during the Sprint Planning meeting where committed items and the main task that have to be done during the sprint are identified. It has to be visible to Scrum team and it can be upgraded during the sprint execution with additional task necessary to achieve the final goal.

===Sprint task===
Every item is divided into several tasks, each of them requires one day or less of work. A sprint task specifies how to achieve what is required by PBI. If the task takes more than one day of work, remaining effort is re-estimated daily, typically in hours.

===Sprint Burndown Chart===
[[File:Sprint_burndown_chart.png|300px|thumb|right|Sprint Burndown Chart<ref name='James'></ref>]]
This tool is used to facilitate self-organization of the team. It indicates the total remaining team task hours within one Sprint. Usually chart shows a decreasing line but if there are some re-estimation it may be possible that line increase for then going down. As picture shows it has a time line in the x axis and the remaining hours of work within one Sprint in the y axis. The advantage of this tool is to show at a first sight at which point of the project you are and the work that is left to complete the Sprint. It is important that this tool is used only as help to Scrum team; in some situations it could become a constraint for developers, in this case Scrum Master has to remove this chart from the room.

=Limitations=
Scrum method was often used in the object-oriented software development. Actually this technique are applied not only on software but also on other products from different sectors like wheelchairs, semiconductors and mortgages.
Scrum has to be used in those projects where people cannot rely on the plan-driven approaches like Waterfall, cause of unknown requirements and technology.
[[File:Graph.png|300px|thumb|right|Predictability of a Project<ref name='James'></ref>]]
Conversely if the projects is placed under precise and stable conditions it is better to use one of the traditional model which allow to have a fixed planning over the whole project. In this case Scrum method would involve in a waste of resources and money because he is working on a field that is not its responsibility.

Michael James in his “Scrum Reference card” explains with a simple graphics in which conditions Scrum should be used and which ones are not. James defines the predictability of the projects on the base of two features: knowledge of the requirements and knowledge of the level of technology required. A project which provides known requirements and a known level of technology should be carried out with a plan-driven model. It these conditions are not met it is better to use an empirical approach like Scrum.<ref name='James'></ref>

=References=
<references/>

Scrum Methodology in Agile Software Development

2015-09-27T09:37:18Z

S150821:

Today market is affected by uncertainly and sudden changes, in these conditions most of the models used in the 20th century to develop software are not still appropriate. Waterfall model , probably the most famous between them, is characterized by a stiff structure which can’t cope with the turbulent needs of actual market.
In recent years many innovations are been enhanced in software engineering with a particular focus on the flexibility of these methods in order to cope with the customer’s and market’s needs; surely '''Agile Software Development''' is between them.

ASD embraces the principles of lean production by applying them in software development to avoid waste and increase responsiveness to change. It represents the solution to the unpredictability of the market where the capacity "to welcome change even late in development" (''K. Beck et all, 2001'')<ref name='Manifesto'></ref> to satisfy customers is required.
This article deals with Agile Software Development with a particular focus on one of its most used technique : '''Scrum Methodology'''.

=Scrum Methodology=
Scrum is an iterative method used to develop software, it can be placed inside the group of methods which are used in '''Agile Software Development'''. This word is taken from rugby and represents that phase of the match where an ordered formation of players, with arms interlocked and heads down, push forward against a similar group to gain possession of the ball. This method provides that "work is divided into small chunks to manage complexity and to get early feedback from customers and end users" (''S. Augustine, 2005'')<ref>S. Augustine,2005,Prentice Hall PTR,Managing Agile Projects</ref>; software development is carried out by small working team that allow rapid adjustment during the process and a quick delivery of the final product.

==Agile Software Development==
Some practitioners believed that traditional iterative model was not so responsive to changes that market required. They thought that to be Agile a process needs to accept change rather than stress predictability and that methods used to develop software has to respond to change as quickly as it arose rather than prevent changes.<ref name='Cohen'>D.Cohen,M.Lindval,P. Costa,Fraunhofer Center Maryland, Agile Software Development</ref>

It was in these circumstances that practitioners as Mary Poppendieck and Bob Charet started to take inspiration from Lean manufacturing principles and apply them to software development.
These are the main points ,according to Poppendieck, which make Lean Production so successful and that can be applied to software development:

*elimination of waste that does not add value to the customer such as diagram and models that do not add value to the final deliverable;
*minimize inventory such as requirements and design documents;
*maximize flow by using iterative development to reduce development time;
*pull from demand;
*empower workers that means “tell developer what needs to be done not how to do it";
*meet customer requirements – work closely with the customer, allowing them to change their minds
*do it right the first time – test early and refactor when necessary;
*abolish local optimization – flexibly manage scope;
*partner with suppliers – avoid adversarial relationships, work towards developing the best software;
*create a culture of continuous improvement – allow the process to improve, learn from mistakes and successes.<ref name='Cohen'></ref><ref>M. Poppendieck, T. Poppendieck, 2003, Addison Wesley, Lean Software Development: An Agile Toolkit[[http://www.poppendieck.com/]]</ref>

===Manifesto for the Agile Software development===
A few years before Poppoendieck’s publication on February 2001 main principles of Agile Software development were stated by a group of 17 software developers which published “Manifesto for the Agile Software Development”.<ref name='Manifesto'>K. Beck et all., 2001, Manifesto for Agile Software Development[http://www.agilemanifesto.org/]</ref>

From reading these few words it is possible to identify what are the main innovations that ASD introduced in Software development:
[[File:Agilemanifesto.jpg|400px|thumb|right|Manifesto for the Agile Software development<ref name='Manifesto'></ref>]]

*'''“Individuals and interactions”''' : with these words founders want to remark the power of human being creativity, and his ability to collaborate with other similar. The stiffness of Waterfall model is instead represented by “processes and tools” where people has to follow only what the plan requires.
*'''“Working software “''' : there is a clear reference to the new way to develop software where at every iteration a working program is realised, differently from the earlier model in which a working program couldn’t be seen until the end of the project. This feature is put over the “comprehensive documentation” which characterizes especially Waterfall model.
*'''“Customer collaboration”''' : means that there must be a straight relationship between customer and developer in order to define time by time the projects requirements and evaluate every realise.
*'''“Responding to change over following a plan”''' : this sentence encloses the essence of Agile software Development that is to cope with turbulent markets by being flexible and by responding quickly to change, instead of being bound by planning. This concept is remarked by the founders in one of the twelve principles which follow the manifesto which says “Welcome changing requirements, even late in development […]”.

=Application=
[[File:Scrum_Framework.png|350px|thumb|right|Scrum Framework]]
There are two concepts that are at the basement of Scrum methodology: '''iterative development''' and '''team working'''. Developing in iterations allow Scrum team to adapt quickly to changing requirements, while working in close location and focusing on communication allow team to make decisions and act on them immediately rather than wait on correspondence.<ref name='Cohen'></ref>

Basically Scrum consists in a sequence of fixed-length iterations called [[Sprint:http://apppm.man.dtu.dk/index.php?title=Scrum_Methodology_in_Agile_Software_Development&action=submit#Sprint|Sprint]] managed by one or more '''cross-functional and self-organizing teams''' each composed by seven people that aim at a common goal and that usually work only on the software development. There are instead other two figures that manage all things that are in support of the development process: one is '''Product Owner''' who mainly handles customers contacts and the other is '''Scrum Master''' whose main task is to ensure that development team can work without obstacles.

Each sprint usually lasts from 2 to 4 weeks, in this period there are at least one meeting between the Product Owner and Development Team to define the main objectives; then there are short daily meetings held every morning to enhance communication and inform customers, developers, and managers on the status of the project, identify any problems encountered, and keep the entire team focused on a common goal.<ref name='Cohen'></ref>

==Main figures in Scrum==
===Product Owner===
Product owner is the link between customers and development team, he ensures that deliverables are in line with customers’ expectation and that stakeholders’ interests are fulfilled. He has also the task to fill out customer-centric items (typically '''user stories'''), ranks and prioritizes them before adds them to '''Product Backlog'''.

Usually development teams have only one Product owner, but differently from the Scrum master, he only takes care of the business side and does not interfere with the scrum team about the technological issues. At the beginning of each Sprint the Product Owner holds a Sprint Planning Meeting to state on which Product Backlog Items Scrum team will go to work during the next Sprint. In this phase he defines what are the most important items for that business, in according to customer’s needs.

===Development Team===
Development team task is to provide Product Backlog Items (PBIs) at the end of every Sprint in according with customers’ requirements after negotiating commitments with the Product Owner.
Usually each team is composed by '''cross-functional members''' that allow an all-round software development; the main figures that there must be are a mix of software engineers, architects, programmers, analysts, QA experts, testers, and UI designers.

The size of the team is an important point, the group members' number influences capacity of people to communicate and work together: it is recommended that a scrum team is composed not more than nine people, usually seven.

Another important characteristic is the Self-organization of the group which facilitates members’ creativity and increases team cohesiveness: for this reason it is better to not change members of a team after they have worked together, especially if they had success in their project. After working together team members gain a mutual understanding that increases their capacity of team working, this synergy cannot be acquired if team are continuously changed.

A further point that characterized the good outcomes of a scrum team is location: people are most successful when located in the same room, particularly for the first few Sprints: this facilitates communication and information sharing.

====Team self-organization====
Team self-organization is a crucial point in the scrum methodology : with this concept it means that “it is told developer what needs to be done not how to do it”, they can autonomously choose the way to reach commitments.
As it is said previously during Sprint execution, team members develop an intrinsic interest in shared goals and learn to manage each other to achieve them, for this reason self-organizing teams can radically outperform larger than traditionally managed teams. It has to be specified that an optimal self-organization takes time: it may be possible that for the first few sprints developers perform worse than when they work in the traditional way.

Some requirements are necessary to gain a good team self-organization:
*members are committed to clear, short-term goals;
*members can gauge the group’s progress;
*members can observe each other’s contribution;
*members feel safe to give each other unvarnished feedback.<ref name='James'>M. James,2010,Scrum Reference Card, Michael James,[[http://scrumreferencecard.com/]]</ref>

Conversely there are some conditions that can hander self-organization:
*geographical distribution: it is better if the whole team work in a room;
*boss/work dynamics: each member has to consider the others as peer to facilitate a fair communication between them;
*part-time team members;
*interruptions unrelated to Sprint goals.

===Scrum Master===
The scrum master worries that Scrum team can work without obstacles but he has no management authority over them. Essentially he has the aim to:
*create an environment to promote team self-organization;
*support team in the achievement of expected goals;
*ensure that events (e.g. daily Scrum meeting) take place in the right way;
*keep '''Scrum artefacts''' visible ('''Product Backlog''', '''Sprint Backlog''', '''Sprint burndown chart''' …).

==Sprint==
Sprint (or iteration) is the fundamental unit in which the work is divided; it is characterized by a fixed length of 2 weeks or 30 days and by a goal to achieve. At the beginning of each sprint Scrum team , Product Owner , Scrum Master and sometimes also stakeholders hold a meeting, called Sprint Planning meeting whose output is the Sprint Backlog where goals and requirements of the next Sprint are defined. Then other meetings inside development team will be held in order to define in more detail how achieving the common goals stated in the previous meeting.
==Scrum Meetings==
[[File:Scrum_meetings.png|350px|thumb|right|Scrum Meetings<ref name='James'></ref>]]
Meeting are a fundamental tool used during the whole Scrum process. Usually they are facilitated by the Scrum master who has no decision-making authority over them . There are different typologies of meetings according to the different phase of the process in which we are.
===Sprint Planning Meeting===
At the beginning of each Sprint, the Product Owner and team hold a Sprint Planning Meeting to define on which '''Product Backlog Items (PBIs)''' they will go to work during the next Sprint. "The Product Owner is responsible for declaring which items are the most important to the business. The team is responsible for selecting the amount of work they feel they can implement" (''M. James, 2010'')<ref name='James'></ref>.In this phase in perfect Lean perspective the team “pulls” work from the Product Backlog to the Sprint Backlog. At the end of the meeting the selected items are broken into a provisional list of Sprint task. The maximum time that can be used to do Planning meeting, known as '''timebox''', is of eight hours.

===Daily Scrum and Sprint Execution===
During the sprint every day members of the Scrum team hold a fifteen minutes meeting where they take stock of the situation. Usually they speak about what they did previous day, which impediments they faced and what they are going to do in the current day. To make these meetings shorter it is better that people are standing.
During sprint execution it is common to find out additional tasks necessary to achieve sprint goal; to keep the control over processes during sprint development it could be useful to maintain a current '''Sprint Task List''', a '''Sprint Burndown Chart''', and an '''Impediments List''': these are some artefacts that allow developer to understand where the project is located.

===Sprint Review Meeting===
At the end of every Sprint it is held a Review meeting where the scrum team has to explain to the Product Owner what they did during the previous sprint. Usually this meeting consists in a live demonstration of the working product increment after which Product Owner states which Items can be considered as done.
Items which are declared not done have to return to the Product Backlog to be ranked and reprioritized by the Product Owner with the help of the Scrum master. Last step of this meeting is to convert stakeholders’ feedback to a new Product Log, this task is consigned to both Product Owner and Scrum Master.
The Sprint Review Meeting is the appropriate meeting for external stakeholders (even end users) to attend.

===Sprint Retrospective Meeting===
During this meeting every member of the scrum team inspects his behaviour to identify some impediments that he faced during Sprint. There are mainly three kind of impediments in which developers can be involved:
*people who conduct performance evaluation are an obstacles to transparency of the team;
*human tendency of someone in the team to jump to conclusions and propose actions too quickly;
*geographical distribution of the team can be an impediments, team work better if they are delimited in a small place like a room.<ref name='James'></ref>

After identifying all these impediments Scrum master has the task to eliminate them.

===Backlog Refinement Meeting ===
Especially at the beginning of the project "most of the Product Backlog Items (PBIs) need refinement because they are too large and poorly understood" (''M. James, 2010'')<ref name='James'></ref>. In the Backlog Refinement Meeting, the team gave an estimation of the work left to complete Items in the Product Backlog and provides other technical information to help the Product Owner prioritize them.

==Artefacts==
[[File:Product_Backlog.png|200px|thumb|right|Product Backlog<ref name='James'></ref>]]
===Product Backlog===

It is defined before the project beginning and then upgraded during the Backlog Refinement meeting ; it is made up by the whole group of items which have to be completed during the project in order to realize the final product. Every item is ranked and constantly reprioritized by the Product Owner. It is important that Product Backlog Is visible to the stakeholders.

===Product Backlog Item (PBI)===
An item specifies what has to be done but not how do it. Usually they are written in a User story to be understood also by stakeholders. Every items has a work load of 2-3 days and requires 2-3 people. It represents the basic unit of Product backlog.
[[File:Sprint_Backlog.png|200px|thumb|right|Sprint Backlog<ref name='James'></ref>]]
===Sprint backlog===

It is defined at the beginning of each sprint during the Sprint Planning meeting where committed items and the main task that have to be done during the sprint are identified. It has to be visible to Scrum team and it can be upgraded during the sprint execution with additional task necessary to achieve the final goal.

===Sprint task===
Every item is divided into several tasks, each of them requires one day or less of work. A sprint task specifies how to achieve what is required by PBI. If the task takes more than one day of work, remaining effort is re-estimated daily, typically in hours.

===Sprint Burndown Chart===
[[File:Sprint_burndown_chart.png|300px|thumb|right|Sprint Burndown Chart<ref name='James'></ref>]]
This tool is used to facilitate self-organization of the team. It indicates the total remaining team task hours within one Sprint. Usually chart shows a decreasing line but if there are some re-estimation it may be possible that line increase for then going down.

=Limitations=
Scrum method was often used in the object-oriented software development. Actually this technique are applied not only on software but also on other products from different sectors like wheelchairs, semiconductors and mortgages.
Scrum has to be used in those projects where people cannot rely on the plan-driven approaches like Waterfall, cause of unknown requirements and technology.
[[File:Graph.png|300px|thumb|right|Predictability of a Project<ref name='James'></ref>]]
Conversely if the projects is placed under precise and stable conditions it is better to use one of the traditional model which allow to have a fixed planning over the whole project. In this case Scrum method would involve in a waste of resources and money because he is working on a field that is not its responsibility.

Michael James in his “Scrum Reference card” explains with a simple graphics in which conditions Scrum should be used and which ones are not. James defines the predictability of the projects on the base of two features: knowledge of the requirements and knowledge of the level of technology required. A project which provides known requirements and a known level of technology should be carried out with a plan-driven model. It these conditions are not met it is better to use an empirical approach like Scrum.<ref name='James'></ref>

=References=
<references/>

Scrum Methodology in Agile Software Development

2015-09-27T09:34:49Z

S150821:

Today market is affected by uncertainly and sudden changes, in these conditions most of the models used in the 20th century to develop software are not still appropriate. Waterfall model , probably the most famous between them, is characterized by a stiff structure which can’t cope with the turbulent needs of actual market.
In recent years many innovations are been enhanced in software engineering with a particular focus on the flexibility of these methods in order to cope with the customer’s and market’s needs; surely '''Agile Software Development''' is between them.

ASD embraces the principles of lean production by applying them in software development to avoid waste and increase responsiveness to change. It represents the solution to the unpredictability of the market where the capacity "to welcome change even late in development"<ref name='Manifesto'></ref> to satisfy customers is required.
This article deals with Agile Software Development with a particular focus on one of its most used technique : '''Scrum Methodology'''.

=Scrum Methodology=
Scrum is an iterative method used to develop software, it can be placed inside the group of methods which are used in '''Agile Software Development'''. This word is taken from rugby and represents that phase of the match where an ordered formation of players, with arms interlocked and heads down, push forward against a similar group to gain possession of the ball. This method provides that "work is divided into small chunks to manage complexity and to get early feedback from customers and end users" (''S. Augustine, 2005'')<ref>S. Augustine,2005,Prentice Hall PTR,Managing Agile Projects</ref>; software development is carried out by small working team that allow rapid adjustment during the process and a quick delivery of the final product.

==Agile Software Development==
Some practitioners believed that traditional iterative model was not so responsive to changes that market required. They thought that to be Agile a process needs to accept change rather than stress predictability and that methods used to develop software has to respond to change as quickly as it arose rather than prevent changes.<ref name='Cohen'>D.Cohen,M.Lindval,P. Costa,Fraunhofer Center Maryland, Agile Software Development</ref>

It was in these circumstances that practitioners as Mary Poppendieck and Bob Charet started to take inspiration from Lean manufacturing principles and apply them to software development.
These are the main points ,according to Poppendieck, which make Lean Production so successful and that can be applied to software development:

*elimination of waste that does not add value to the customer such as diagram and models that do not add value to the final deliverable;
*minimize inventory such as requirements and design documents;
*maximize flow by using iterative development to reduce development time;
*pull from demand;
*empower workers that means “tell developer what needs to be done not how to do it";
*meet customer requirements – work closely with the customer, allowing them to change their minds
*do it right the first time – test early and refactor when necessary;
*abolish local optimization – flexibly manage scope;
*partner with suppliers – avoid adversarial relationships, work towards developing the best software;
*create a culture of continuous improvement – allow the process to improve, learn from mistakes and successes.<ref name='Cohen'></ref><ref>M. Poppendieck, T. Poppendieck, 2003, Addison Wesley, Lean Software Development: An Agile Toolkit[[http://www.poppendieck.com/]]</ref>

===Manifesto for the Agile Software development===
A few years before Poppoendieck’s publication on February 2001 main principles of Agile Software development were stated by a group of 17 software developers which published “Manifesto for the Agile Software Development”.<ref name='Manifesto'>K. Beck et all., 2001, Manifesto for Agile Software Development[http://www.agilemanifesto.org/]</ref>

From reading these few words it is possible to identify what are the main innovations that ASD introduced in Software development:
[[File:Agilemanifesto.jpg|400px|thumb|right|Manifesto for the Agile Software development<ref name='Manifesto'></ref>]]

*'''“Individuals and interactions”''' : with these words founders want to remark the power of human being creativity, and his ability to collaborate with other similar. The stiffness of Waterfall model is instead represented by “processes and tools” where people has to follow only what the plan requires.
*'''“Working software “''' : there is a clear reference to the new way to develop software where at every iteration a working program is realised, differently from the earlier model in which a working program couldn’t be seen until the end of the project. This feature is put over the “comprehensive documentation” which characterizes especially Waterfall model.
*'''“Customer collaboration”''' : means that there must be a straight relationship between customer and developer in order to define time by time the projects requirements and evaluate every realise.
*'''“Responding to change over following a plan”''' : this sentence encloses the essence of Agile software Development that is to cope with turbulent markets by being flexible and by responding quickly to change, instead of being bound by planning. This concept is remarked by the founders in one of the twelve principles which follow the manifesto which says “Welcome changing requirements, even late in development […]”.

=Application=
[[File:Scrum_Framework.png|350px|thumb|right|Scrum Framework]]
There are two concepts that are at the basement of Scrum methodology: '''iterative development''' and '''team working'''. Developing in iterations allow Scrum team to adapt quickly to changing requirements, while working in close location and focusing on communication allow team to make decisions and act on them immediately rather than wait on correspondence.<ref name='Cohen'></ref>

Basically Scrum consists in a sequence of fixed-length iterations called [[Sprint:http://apppm.man.dtu.dk/index.php?title=Scrum_Methodology_in_Agile_Software_Development&action=submit#Sprint|Sprint]] managed by one or more '''cross-functional and self-organizing teams''' each composed by seven people that aim at a common goal and that usually work only on the software development. There are instead other two figures that manage all things that are in support of the development process: one is '''Product Owner''' who mainly handles customers contacts and the other is '''Scrum Master''' whose main task is to ensure that development team can work without obstacles.

Each sprint usually lasts from 2 to 4 weeks, in this period there are at least one meeting between the Product Owner and Development Team to define the main objectives; then there are short daily meetings held every morning to enhance communication and inform customers, developers, and managers on the status of the project, identify any problems encountered, and keep the entire team focused on a common goal.<ref name='Cohen'></ref>

==Main figures in Scrum==
===Product Owner===
Product owner is the link between customers and development team, he ensures that deliverables are in line with customers’ expectation and that stakeholders’ interests are fulfilled. He has also the task to fill out customer-centric items (typically '''user stories'''), ranks and prioritizes them before adds them to '''Product Backlog'''.

Usually development teams have only one Product owner, but differently from the Scrum master, he only takes care of the business side and does not interfere with the scrum team about the technological issues. At the beginning of each Sprint the Product Owner holds a Sprint Planning Meeting to state on which Product Backlog Items Scrum team will go to work during the next Sprint. In this phase he defines what are the most important items for that business, in according to customer’s needs.

===Development Team===
Development team task is to provide Product Backlog Items (PBIs) at the end of every Sprint in according with customers’ requirements after negotiating commitments with the Product Owner.
Usually each team is composed by '''cross-functional members''' that allow an all-round software development; the main figures that there must be are a mix of software engineers, architects, programmers, analysts, QA experts, testers, and UI designers.

The size of the team is an important point, the group members' number influences capacity of people to communicate and work together: it is recommended that a scrum team is composed not more than nine people, usually seven.

Another important characteristic is the Self-organization of the group which facilitates members’ creativity and increases team cohesiveness: for this reason it is better to not change members of a team after they have worked together, especially if they had success in their project. After working together team members gain a mutual understanding that increases their capacity of team working, this synergy cannot be acquired if team are continuously changed.

A further point that characterized the good outcomes of a scrum team is location: people are most successful when located in the same room, particularly for the first few Sprints: this facilitates communication and information sharing.

====Team self-organization====
Team self-organization is a crucial point in the scrum methodology : with this concept it means that “it is told developer what needs to be done not how to do it”, they can autonomously choose the way to reach commitments.
As it is said previously during Sprint execution, team members develop an intrinsic interest in shared goals and learn to manage each other to achieve them, for this reason self-organizing teams can radically outperform larger than traditionally managed teams. It has to be specified that an optimal self-organization takes time: it may be possible that for the first few sprints developers perform worse than when they work in the traditional way.

Some requirements are necessary to gain a good team self-organization:
*members are committed to clear, short-term goals;
*members can gauge the group’s progress;
*members can observe each other’s contribution;
*members feel safe to give each other unvarnished feedback.<ref name='James'>M. James,2010,Scrum Reference Card, Michael James,[[http://scrumreferencecard.com/]]</ref>

Conversely there are some conditions that can hander self-organization:
*geographical distribution: it is better if the whole team work in a room;
*boss/work dynamics: each member has to consider the others as peer to facilitate a fair communication between them;
*part-time team members;
*interruptions unrelated to Sprint goals.

===Scrum Master===
The scrum master worries that Scrum team can work without obstacles but he has no management authority over them. Essentially he has the aim to:
*create an environment to promote team self-organization;
*support team in the achievement of expected goals;
*ensure that events (e.g. daily Scrum meeting) take place in the right way;
*keep '''Scrum artefacts''' visible ('''Product Backlog''', '''Sprint Backlog''', '''Sprint burndown chart''' …).

==Sprint==
Sprint (or iteration) is the fundamental unit in which the work is divided; it is characterized by a fixed length of 2 weeks or 30 days and by a goal to achieve. At the beginning of each sprint Scrum team , Product Owner , Scrum Master and sometimes also stakeholders hold a meeting, called Sprint Planning meeting whose output is the Sprint Backlog where goals and requirements of the next Sprint are defined. Then other meetings inside development team will be held in order to define in more detail how achieving the common goals stated in the previous meeting.
==Scrum Meetings==
[[File:Scrum_meetings.png|350px|thumb|right|Scrum Meetings<ref name='James'></ref>]]
Meeting are a fundamental tool used during the whole Scrum process. Usually they are facilitated by the Scrum master who has no decision-making authority over them . There are different typologies of meetings according to the different phase of the process in which we are.
===Sprint Planning Meeting===
At the beginning of each Sprint, the Product Owner and team hold a Sprint Planning Meeting to define on which '''Product Backlog Items (PBIs)''' they will go to work during the next Sprint. "The Product Owner is responsible for declaring which items are the most important to the business. The team is responsible for selecting the amount of work they feel they can implement" (''M. James, 2010'')<ref name='James'></ref>.In this phase in perfect Lean perspective the team “pulls” work from the Product Backlog to the Sprint Backlog. At the end of the meeting the selected items are broken into a provisional list of Sprint task. The maximum time that can be used to do Planning meeting, known as '''timebox''', is of eight hours.

===Daily Scrum and Sprint Execution===
During the sprint every day members of the Scrum team hold a fifteen minutes meeting where they take stock of the situation. Usually they speak about what they did previous day, which impediments they faced and what they are going to do in the current day. To make these meetings shorter it is better that people are standing.
During sprint execution it is common to find out additional tasks necessary to achieve sprint goal; to keep the control over processes during sprint development it could be useful to maintain a current '''Sprint Task List''', a '''Sprint Burndown Chart''', and an '''Impediments List''': these are some artefacts that allow developer to understand where the project is located.

===Sprint Review Meeting===
At the end of every Sprint it is held a Review meeting where the scrum team has to explain to the Product Owner what they did during the previous sprint. Usually this meeting consists in a live demonstration of the working product increment after which Product Owner states which Items can be considered as done.
Items which are declared not done have to return to the Product Backlog to be ranked and reprioritized by the Product Owner with the help of the Scrum master. Last step of this meeting is to convert stakeholders’ feedback to a new Product Log, this task is consigned to both Product Owner and Scrum Master.
The Sprint Review Meeting is the appropriate meeting for external stakeholders (even end users) to attend.

===Sprint Retrospective Meeting===
During this meeting every member of the scrum team inspects his behaviour to identify some impediments that he faced during Sprint. There are mainly three kind of impediments in which developers can be involved:
*people who conduct performance evaluation are an obstacles to transparency of the team;
*human tendency of someone in the team to jump to conclusions and propose actions too quickly;
*geographical distribution of the team can be an impediments, team work better if they are delimited in a small place like a room.<ref name='James'></ref>

After identifying all these impediments Scrum master has the task to eliminate them.

===Backlog Refinement Meeting ===
Especially at the beginning of the project "most of the Product Backlog Items (PBIs) need refinement because they are too large and poorly understood" (''M. James, 2010'')<ref name='James'></ref>. In the Backlog Refinement Meeting, the team gave an estimation of the work left to complete Items in the Product Backlog and provides other technical information to help the Product Owner prioritize them.

==Artefacts==
[[File:Product_Backlog.png|200px|thumb|right|Product Backlog<ref name='James'></ref>]]
===Product Backlog===

It is defined before the project beginning and then upgraded during the Backlog Refinement meeting ; it is made up by the whole group of items which have to be completed during the project in order to realize the final product. Every item is ranked and constantly reprioritized by the Product Owner. It is important that Product Backlog Is visible to the stakeholders.

===Product Backlog Item (PBI)===
An item specifies what has to be done but not how do it. Usually they are written in a User story to be understood also by stakeholders. Every items has a work load of 2-3 days and requires 2-3 people. It represents the basic unit of Product backlog.
[[File:Sprint_Backlog.png|200px|thumb|right|Sprint Backlog<ref name='James'></ref>]]
===Sprint backlog===

It is defined at the beginning of each sprint during the Sprint Planning meeting where committed items and the main task that have to be done during the sprint are identified. It has to be visible to Scrum team and it can be upgraded during the sprint execution with additional task necessary to achieve the final goal.

===Sprint task===
Every item is divided into several tasks, each of them requires one day or less of work. A sprint task specifies how to achieve what is required by PBI. If the task takes more than one day of work, remaining effort is re-estimated daily, typically in hours.

===Sprint Burndown Chart===
[[File:Sprint_burndown_chart.png|300px|thumb|right|Sprint Burndown Chart<ref name='James'></ref>]]
This tool is used to facilitate self-organization of the team. It indicates the total remaining team task hours within one Sprint. Usually chart shows a decreasing line but if there are some re-estimation it may be possible that line increase for then going down.

=Limitations=
Scrum method was often used in the object-oriented software development. Actually this technique are applied not only on software but also on other products from different sectors like wheelchairs, semiconductors and mortgages.
Scrum has to be used in those projects where people cannot rely on the plan-driven approaches like Waterfall, cause of unknown requirements and technology.
[[File:Graph.png|300px|thumb|right|Predictability of a Project<ref name='James'></ref>]]
Conversely if the projects is placed under precise and stable conditions it is better to use one of the traditional model which allow to have a fixed planning over the whole project. In this case Scrum method would involve in a waste of resources and money because he is working on a field that is not its responsibility.

Michael James in his “Scrum Reference card” explains with a simple graphics in which conditions Scrum should be used and which ones are not. James defines the predictability of the projects on the base of two features: knowledge of the requirements and knowledge of the level of technology required. A project which provides known requirements and a known level of technology should be carried out with a plan-driven model. It these conditions are not met it is better to use an empirical approach like Scrum.<ref name='James'></ref>

=References=
<references/>

Scrum Methodology in Agile Software Development

2015-09-27T09:32:58Z

S150821: /* Manifesto for the Agile Software development */

Today market is affected by uncertainly and sudden changes, in these conditions most of the models used in the 20th century to develop software are not still appropriate. Waterfall model , probably the most famous between them, is characterized by a stiff structure which can’t cope with the turbulent needs of actual market.
In recent years many innovations are been enhanced in software engineering with a particular focus on the flexibility of these methods in order to cope with the customer’s and market’s needs; surely '''Agile Software Development''' is between them.

ASD embraces the principles of lean production by applying them in software development to avoid waste and increase responsiveness to change. It represents the solution to the unpredictability of the market where the capacity to welcome change even late in development to satisfy customers is required.
This article deals with Agile Software Development with a particular focus on one of its most used technique : '''Scrum Methodology'''.

=Scrum Methodology=
Scrum is an iterative method used to develop software, it can be placed inside the group of methods which are used in '''Agile Software Development'''. This word is taken from rugby and represents that phase of the match where an ordered formation of players, with arms interlocked and heads down, push forward against a similar group to gain possession of the ball. This method provides that "work is divided into small chunks to manage complexity and to get early feedback from customers and end users" (''S. Augustine, 2005'')<ref>S. Augustine,2005,Prentice Hall PTR,Managing Agile Projects</ref>; software development is carried out by small working team that allow rapid adjustment during the process and a quick delivery of the final product.

==Agile Software Development==
Some practitioners believed that traditional iterative model was not so responsive to changes that market required. They thought that to be Agile a process needs to accept change rather than stress predictability and that methods used to develop software has to respond to change as quickly as it arose rather than prevent changes.<ref name='Cohen'>D.Cohen,M.Lindval,P. Costa,Fraunhofer Center Maryland, Agile Software Development</ref>

It was in these circumstances that practitioners as Mary Poppendieck and Bob Charet started to take inspiration from Lean manufacturing principles and apply them to software development.
These are the main points ,according to Poppendieck, which make Lean Production so successful and that can be applied to software development:

*elimination of waste that does not add value to the customer such as diagram and models that do not add value to the final deliverable;
*minimize inventory such as requirements and design documents;
*maximize flow by using iterative development to reduce development time;
*pull from demand;
*empower workers that means “tell developer what needs to be done not how to do it";
*meet customer requirements – work closely with the customer, allowing them to change their minds
*do it right the first time – test early and refactor when necessary;
*abolish local optimization – flexibly manage scope;
*partner with suppliers – avoid adversarial relationships, work towards developing the best software;
*create a culture of continuous improvement – allow the process to improve, learn from mistakes and successes.<ref name='Cohen'></ref><ref>M. Poppendieck, T. Poppendieck, 2003, Addison Wesley, Lean Software Development: An Agile Toolkit[[http://www.poppendieck.com/]]</ref>

===Manifesto for the Agile Software development===
A few years before Poppoendieck’s publication on February 2001 main principles of Agile Software development were stated by a group of 17 software developers which published “Manifesto for the Agile Software Development”.<ref name='Manifesto'>K. Beck et all., 2001, Manifesto for Agile Software Development[http://www.agilemanifesto.org/]</ref>

From reading these few words it is possible to identify what are the main innovations that ASD introduced in Software development:
[[File:Agilemanifesto.jpg|400px|thumb|right|Manifesto for the Agile Software development<ref name='Manifesto'></ref>]]

*'''“Individuals and interactions”''' : with these words founders want to remark the power of human being creativity, and his ability to collaborate with other similar. The stiffness of Waterfall model is instead represented by “processes and tools” where people has to follow only what the plan requires.
*'''“Working software “''' : there is a clear reference to the new way to develop software where at every iteration a working program is realised, differently from the earlier model in which a working program couldn’t be seen until the end of the project. This feature is put over the “comprehensive documentation” which characterizes especially Waterfall model.
*'''“Customer collaboration”''' : means that there must be a straight relationship between customer and developer in order to define time by time the projects requirements and evaluate every realise.
*'''“Responding to change over following a plan”''' : this sentence encloses the essence of Agile software Development that is to cope with turbulent markets by being flexible and by responding quickly to change, instead of being bound by planning. This concept is remarked by the founders in one of the twelve principles which follow the manifesto which says “Welcome changing requirements, even late in development […]”.

=Application=
[[File:Scrum_Framework.png|350px|thumb|right|Scrum Framework]]
There are two concepts that are at the basement of Scrum methodology: '''iterative development''' and '''team working'''. Developing in iterations allow Scrum team to adapt quickly to changing requirements, while working in close location and focusing on communication allow team to make decisions and act on them immediately rather than wait on correspondence.<ref name='Cohen'></ref>

Basically Scrum consists in a sequence of fixed-length iterations called [[Sprint:http://apppm.man.dtu.dk/index.php?title=Scrum_Methodology_in_Agile_Software_Development&action=submit#Sprint|Sprint]] managed by one or more '''cross-functional and self-organizing teams''' each composed by seven people that aim at a common goal and that usually work only on the software development. There are instead other two figures that manage all things that are in support of the development process: one is '''Product Owner''' who mainly handles customers contacts and the other is '''Scrum Master''' whose main task is to ensure that development team can work without obstacles.

Each sprint usually lasts from 2 to 4 weeks, in this period there are at least one meeting between the Product Owner and Development Team to define the main objectives; then there are short daily meetings held every morning to enhance communication and inform customers, developers, and managers on the status of the project, identify any problems encountered, and keep the entire team focused on a common goal.<ref name='Cohen'></ref>

==Main figures in Scrum==
===Product Owner===
Product owner is the link between customers and development team, he ensures that deliverables are in line with customers’ expectation and that stakeholders’ interests are fulfilled. He has also the task to fill out customer-centric items (typically '''user stories'''), ranks and prioritizes them before adds them to '''Product Backlog'''.

Usually development teams have only one Product owner, but differently from the Scrum master, he only takes care of the business side and does not interfere with the scrum team about the technological issues. At the beginning of each Sprint the Product Owner holds a Sprint Planning Meeting to state on which Product Backlog Items Scrum team will go to work during the next Sprint. In this phase he defines what are the most important items for that business, in according to customer’s needs.

===Development Team===
Development team task is to provide Product Backlog Items (PBIs) at the end of every Sprint in according with customers’ requirements after negotiating commitments with the Product Owner.
Usually each team is composed by '''cross-functional members''' that allow an all-round software development; the main figures that there must be are a mix of software engineers, architects, programmers, analysts, QA experts, testers, and UI designers.

The size of the team is an important point, the group members' number influences capacity of people to communicate and work together: it is recommended that a scrum team is composed not more than nine people, usually seven.

Another important characteristic is the Self-organization of the group which facilitates members’ creativity and increases team cohesiveness: for this reason it is better to not change members of a team after they have worked together, especially if they had success in their project. After working together team members gain a mutual understanding that increases their capacity of team working, this synergy cannot be acquired if team are continuously changed.

A further point that characterized the good outcomes of a scrum team is location: people are most successful when located in the same room, particularly for the first few Sprints: this facilitates communication and information sharing.

====Team self-organization====
Team self-organization is a crucial point in the scrum methodology : with this concept it means that “it is told developer what needs to be done not how to do it”, they can autonomously choose the way to reach commitments.
As it is said previously during Sprint execution, team members develop an intrinsic interest in shared goals and learn to manage each other to achieve them, for this reason self-organizing teams can radically outperform larger than traditionally managed teams. It has to be specified that an optimal self-organization takes time: it may be possible that for the first few sprints developers perform worse than when they work in the traditional way.

Some requirements are necessary to gain a good team self-organization:
*members are committed to clear, short-term goals;
*members can gauge the group’s progress;
*members can observe each other’s contribution;
*members feel safe to give each other unvarnished feedback.<ref name='James'>M. James,2010,Scrum Reference Card, Michael James,[[http://scrumreferencecard.com/]]</ref>

Conversely there are some conditions that can hander self-organization:
*geographical distribution: it is better if the whole team work in a room;
*boss/work dynamics: each member has to consider the others as peer to facilitate a fair communication between them;
*part-time team members;
*interruptions unrelated to Sprint goals.

===Scrum Master===
The scrum master worries that Scrum team can work without obstacles but he has no management authority over them. Essentially he has the aim to:
*create an environment to promote team self-organization;
*support team in the achievement of expected goals;
*ensure that events (e.g. daily Scrum meeting) take place in the right way;
*keep '''Scrum artefacts''' visible ('''Product Backlog''', '''Sprint Backlog''', '''Sprint burndown chart''' …).

==Sprint==
Sprint (or iteration) is the fundamental unit in which the work is divided; it is characterized by a fixed length of 2 weeks or 30 days and by a goal to achieve. At the beginning of each sprint Scrum team , Product Owner , Scrum Master and sometimes also stakeholders hold a meeting, called Sprint Planning meeting whose output is the Sprint Backlog where goals and requirements of the next Sprint are defined. Then other meetings inside development team will be held in order to define in more detail how achieving the common goals stated in the previous meeting.
==Scrum Meetings==
[[File:Scrum_meetings.png|350px|thumb|right|Scrum Meetings<ref name='James'></ref>]]
Meeting are a fundamental tool used during the whole Scrum process. Usually they are facilitated by the Scrum master who has no decision-making authority over them . There are different typologies of meetings according to the different phase of the process in which we are.
===Sprint Planning Meeting===
At the beginning of each Sprint, the Product Owner and team hold a Sprint Planning Meeting to define on which '''Product Backlog Items (PBIs)''' they will go to work during the next Sprint. "The Product Owner is responsible for declaring which items are the most important to the business. The team is responsible for selecting the amount of work they feel they can implement" (''M. James, 2010'')<ref name='James'></ref>.In this phase in perfect Lean perspective the team “pulls” work from the Product Backlog to the Sprint Backlog. At the end of the meeting the selected items are broken into a provisional list of Sprint task. The maximum time that can be used to do Planning meeting, known as '''timebox''', is of eight hours.

===Daily Scrum and Sprint Execution===
During the sprint every day members of the Scrum team hold a fifteen minutes meeting where they take stock of the situation. Usually they speak about what they did previous day, which impediments they faced and what they are going to do in the current day. To make these meetings shorter it is better that people are standing.
During sprint execution it is common to find out additional tasks necessary to achieve sprint goal; to keep the control over processes during sprint development it could be useful to maintain a current '''Sprint Task List''', a '''Sprint Burndown Chart''', and an '''Impediments List''': these are some artefacts that allow developer to understand where the project is located.

===Sprint Review Meeting===
At the end of every Sprint it is held a Review meeting where the scrum team has to explain to the Product Owner what they did during the previous sprint. Usually this meeting consists in a live demonstration of the working product increment after which Product Owner states which Items can be considered as done.
Items which are declared not done have to return to the Product Backlog to be ranked and reprioritized by the Product Owner with the help of the Scrum master. Last step of this meeting is to convert stakeholders’ feedback to a new Product Log, this task is consigned to both Product Owner and Scrum Master.
The Sprint Review Meeting is the appropriate meeting for external stakeholders (even end users) to attend.

===Sprint Retrospective Meeting===
During this meeting every member of the scrum team inspects his behaviour to identify some impediments that he faced during Sprint. There are mainly three kind of impediments in which developers can be involved:
*people who conduct performance evaluation are an obstacles to transparency of the team;
*human tendency of someone in the team to jump to conclusions and propose actions too quickly;
*geographical distribution of the team can be an impediments, team work better if they are delimited in a small place like a room.<ref name='James'></ref>

After identifying all these impediments Scrum master has the task to eliminate them.

===Backlog Refinement Meeting ===
Especially at the beginning of the project "most of the Product Backlog Items (PBIs) need refinement because they are too large and poorly understood" (''M. James, 2010'')<ref name='James'></ref>. In the Backlog Refinement Meeting, the team gave an estimation of the work left to complete Items in the Product Backlog and provides other technical information to help the Product Owner prioritize them.

==Artefacts==
[[File:Product_Backlog.png|200px|thumb|right|Product Backlog<ref name='James'></ref>]]
===Product Backlog===

It is defined before the project beginning and then upgraded during the Backlog Refinement meeting ; it is made up by the whole group of items which have to be completed during the project in order to realize the final product. Every item is ranked and constantly reprioritized by the Product Owner. It is important that Product Backlog Is visible to the stakeholders.

===Product Backlog Item (PBI)===
An item specifies what has to be done but not how do it. Usually they are written in a User story to be understood also by stakeholders. Every items has a work load of 2-3 days and requires 2-3 people. It represents the basic unit of Product backlog.
[[File:Sprint_Backlog.png|200px|thumb|right|Sprint Backlog<ref name='James'></ref>]]
===Sprint backlog===

It is defined at the beginning of each sprint during the Sprint Planning meeting where committed items and the main task that have to be done during the sprint are identified. It has to be visible to Scrum team and it can be upgraded during the sprint execution with additional task necessary to achieve the final goal.

===Sprint task===
Every item is divided into several tasks, each of them requires one day or less of work. A sprint task specifies how to achieve what is required by PBI. If the task takes more than one day of work, remaining effort is re-estimated daily, typically in hours.

===Sprint Burndown Chart===
[[File:Sprint_burndown_chart.png|300px|thumb|right|Sprint Burndown Chart<ref name='James'></ref>]]
This tool is used to facilitate self-organization of the team. It indicates the total remaining team task hours within one Sprint. Usually chart shows a decreasing line but if there are some re-estimation it may be possible that line increase for then going down.

=Limitations=
Scrum method was often used in the object-oriented software development. Actually this technique are applied not only on software but also on other products from different sectors like wheelchairs, semiconductors and mortgages.
Scrum has to be used in those projects where people cannot rely on the plan-driven approaches like Waterfall, cause of unknown requirements and technology.
[[File:Graph.png|300px|thumb|right|Predictability of a Project<ref name='James'></ref>]]
Conversely if the projects is placed under precise and stable conditions it is better to use one of the traditional model which allow to have a fixed planning over the whole project. In this case Scrum method would involve in a waste of resources and money because he is working on a field that is not its responsibility.

Michael James in his “Scrum Reference card” explains with a simple graphics in which conditions Scrum should be used and which ones are not. James defines the predictability of the projects on the base of two features: knowledge of the requirements and knowledge of the level of technology required. A project which provides known requirements and a known level of technology should be carried out with a plan-driven model. It these conditions are not met it is better to use an empirical approach like Scrum.<ref name='James'></ref>

=References=
<references/>

Scrum Methodology in Agile Software Development

2015-09-27T09:29:50Z

S150821: /* Limitations */

Today market is affected by uncertainly and sudden changes, in these conditions most of the models used in the 20th century to develop software are not still appropriate. Waterfall model , probably the most famous between them, is characterized by a stiff structure which can’t cope with the turbulent needs of actual market.
In recent years many innovations are been enhanced in software engineering with a particular focus on the flexibility of these methods in order to cope with the customer’s and market’s needs; surely '''Agile Software Development''' is between them.

ASD embraces the principles of lean production by applying them in software development to avoid waste and increase responsiveness to change. It represents the solution to the unpredictability of the market where the capacity to welcome change even late in development to satisfy customers is required.
This article deals with Agile Software Development with a particular focus on one of its most used technique : '''Scrum Methodology'''.

=Scrum Methodology=
Scrum is an iterative method used to develop software, it can be placed inside the group of methods which are used in '''Agile Software Development'''. This word is taken from rugby and represents that phase of the match where an ordered formation of players, with arms interlocked and heads down, push forward against a similar group to gain possession of the ball. This method provides that "work is divided into small chunks to manage complexity and to get early feedback from customers and end users" (''S. Augustine, 2005'')<ref>S. Augustine,2005,Prentice Hall PTR,Managing Agile Projects</ref>; software development is carried out by small working team that allow rapid adjustment during the process and a quick delivery of the final product.

==Agile Software Development==
Some practitioners believed that traditional iterative model was not so responsive to changes that market required. They thought that to be Agile a process needs to accept change rather than stress predictability and that methods used to develop software has to respond to change as quickly as it arose rather than prevent changes.<ref name='Cohen'>D.Cohen,M.Lindval,P. Costa,Fraunhofer Center Maryland, Agile Software Development</ref>

It was in these circumstances that practitioners as Mary Poppendieck and Bob Charet started to take inspiration from Lean manufacturing principles and apply them to software development.
These are the main points ,according to Poppendieck, which make Lean Production so successful and that can be applied to software development:

*elimination of waste that does not add value to the customer such as diagram and models that do not add value to the final deliverable;
*minimize inventory such as requirements and design documents;
*maximize flow by using iterative development to reduce development time;
*pull from demand;
*empower workers that means “tell developer what needs to be done not how to do it";
*meet customer requirements – work closely with the customer, allowing them to change their minds
*do it right the first time – test early and refactor when necessary;
*abolish local optimization – flexibly manage scope;
*partner with suppliers – avoid adversarial relationships, work towards developing the best software;
*create a culture of continuous improvement – allow the process to improve, learn from mistakes and successes.<ref name='Cohen'></ref><ref>M. Poppendieck, T. Poppendieck, 2003, Addison Wesley, Lean Software Development: An Agile Toolkit[[http://www.poppendieck.com/]]</ref>

===Manifesto for the Agile Software development===
A few years before Poppoendieck’s publication on February 2001 main principles of Agile Software development were stated by a group of 17 software developers which published “Manifesto for the Agile Software Development”.<ref>K. Beck et all., 2001, Manifesto for Agile Software Development[http://www.agilemanifesto.org/]</ref>

From reading these few words it is possible to identify what are the main innovations that ASD introduced in Software development:
[[File:Agilemanifesto.jpg|400px|thumb|right|Manifesto for the Agile Software development]]

*'''“Individuals and interactions”''' : with these words founders want to remark the power of human being creativity, and his ability to collaborate with other similar. The stiffness of Waterfall model is instead represented by “processes and tools” where people has to follow only what the plan requires.
*'''“Working software “''' : there is a clear reference to the new way to develop software where at every iteration a working program is realised, differently from the earlier model in which a working program couldn’t be seen until the end of the project. This feature is put over the “comprehensive documentation” which characterizes especially Waterfall model.
*'''“Customer collaboration”''' : means that there must be a straight relationship between customer and developer in order to define time by time the projects requirements and evaluate every realise.
*'''“Responding to change over following a plan”''' : this sentence encloses the essence of Agile software Development that is to cope with turbulent markets by being flexible and by responding quickly to change, instead of being bound by planning. This concept is remarked by the founders in one of the twelve principles which follow the manifesto which says “Welcome changing requirements, even late in development […]”.

=Application=
[[File:Scrum_Framework.png|350px|thumb|right|Scrum Framework]]
There are two concepts that are at the basement of Scrum methodology: '''iterative development''' and '''team working'''. Developing in iterations allow Scrum team to adapt quickly to changing requirements, while working in close location and focusing on communication allow team to make decisions and act on them immediately rather than wait on correspondence.<ref name='Cohen'></ref>

Basically Scrum consists in a sequence of fixed-length iterations called [[Sprint:http://apppm.man.dtu.dk/index.php?title=Scrum_Methodology_in_Agile_Software_Development&action=submit#Sprint|Sprint]] managed by one or more '''cross-functional and self-organizing teams''' each composed by seven people that aim at a common goal and that usually work only on the software development. There are instead other two figures that manage all things that are in support of the development process: one is '''Product Owner''' who mainly handles customers contacts and the other is '''Scrum Master''' whose main task is to ensure that development team can work without obstacles.

Each sprint usually lasts from 2 to 4 weeks, in this period there are at least one meeting between the Product Owner and Development Team to define the main objectives; then there are short daily meetings held every morning to enhance communication and inform customers, developers, and managers on the status of the project, identify any problems encountered, and keep the entire team focused on a common goal.<ref name='Cohen'></ref>

==Main figures in Scrum==
===Product Owner===
Product owner is the link between customers and development team, he ensures that deliverables are in line with customers’ expectation and that stakeholders’ interests are fulfilled. He has also the task to fill out customer-centric items (typically '''user stories'''), ranks and prioritizes them before adds them to '''Product Backlog'''.

Usually development teams have only one Product owner, but differently from the Scrum master, he only takes care of the business side and does not interfere with the scrum team about the technological issues. At the beginning of each Sprint the Product Owner holds a Sprint Planning Meeting to state on which Product Backlog Items Scrum team will go to work during the next Sprint. In this phase he defines what are the most important items for that business, in according to customer’s needs.

===Development Team===
Development team task is to provide Product Backlog Items (PBIs) at the end of every Sprint in according with customers’ requirements after negotiating commitments with the Product Owner.
Usually each team is composed by '''cross-functional members''' that allow an all-round software development; the main figures that there must be are a mix of software engineers, architects, programmers, analysts, QA experts, testers, and UI designers.

The size of the team is an important point, the group members' number influences capacity of people to communicate and work together: it is recommended that a scrum team is composed not more than nine people, usually seven.

Another important characteristic is the Self-organization of the group which facilitates members’ creativity and increases team cohesiveness: for this reason it is better to not change members of a team after they have worked together, especially if they had success in their project. After working together team members gain a mutual understanding that increases their capacity of team working, this synergy cannot be acquired if team are continuously changed.

A further point that characterized the good outcomes of a scrum team is location: people are most successful when located in the same room, particularly for the first few Sprints: this facilitates communication and information sharing.

====Team self-organization====
Team self-organization is a crucial point in the scrum methodology : with this concept it means that “it is told developer what needs to be done not how to do it”, they can autonomously choose the way to reach commitments.
As it is said previously during Sprint execution, team members develop an intrinsic interest in shared goals and learn to manage each other to achieve them, for this reason self-organizing teams can radically outperform larger than traditionally managed teams. It has to be specified that an optimal self-organization takes time: it may be possible that for the first few sprints developers perform worse than when they work in the traditional way.

Some requirements are necessary to gain a good team self-organization:
*members are committed to clear, short-term goals;
*members can gauge the group’s progress;
*members can observe each other’s contribution;
*members feel safe to give each other unvarnished feedback.<ref name='James'>M. James,2010,Scrum Reference Card, Michael James,[[http://scrumreferencecard.com/]]</ref>

Conversely there are some conditions that can hander self-organization:
*geographical distribution: it is better if the whole team work in a room;
*boss/work dynamics: each member has to consider the others as peer to facilitate a fair communication between them;
*part-time team members;
*interruptions unrelated to Sprint goals.

===Scrum Master===
The scrum master worries that Scrum team can work without obstacles but he has no management authority over them. Essentially he has the aim to:
*create an environment to promote team self-organization;
*support team in the achievement of expected goals;
*ensure that events (e.g. daily Scrum meeting) take place in the right way;
*keep '''Scrum artefacts''' visible ('''Product Backlog''', '''Sprint Backlog''', '''Sprint burndown chart''' …).

==Sprint==
Sprint (or iteration) is the fundamental unit in which the work is divided; it is characterized by a fixed length of 2 weeks or 30 days and by a goal to achieve. At the beginning of each sprint Scrum team , Product Owner , Scrum Master and sometimes also stakeholders hold a meeting, called Sprint Planning meeting whose output is the Sprint Backlog where goals and requirements of the next Sprint are defined. Then other meetings inside development team will be held in order to define in more detail how achieving the common goals stated in the previous meeting.
==Scrum Meetings==
[[File:Scrum_meetings.png|350px|thumb|right|Scrum Meetings<ref name='James'></ref>]]
Meeting are a fundamental tool used during the whole Scrum process. Usually they are facilitated by the Scrum master who has no decision-making authority over them . There are different typologies of meetings according to the different phase of the process in which we are.
===Sprint Planning Meeting===
At the beginning of each Sprint, the Product Owner and team hold a Sprint Planning Meeting to define on which '''Product Backlog Items (PBIs)''' they will go to work during the next Sprint. "The Product Owner is responsible for declaring which items are the most important to the business. The team is responsible for selecting the amount of work they feel they can implement" (''M. James, 2010'')<ref name='James'></ref>.In this phase in perfect Lean perspective the team “pulls” work from the Product Backlog to the Sprint Backlog. At the end of the meeting the selected items are broken into a provisional list of Sprint task. The maximum time that can be used to do Planning meeting, known as '''timebox''', is of eight hours.

===Daily Scrum and Sprint Execution===
During the sprint every day members of the Scrum team hold a fifteen minutes meeting where they take stock of the situation. Usually they speak about what they did previous day, which impediments they faced and what they are going to do in the current day. To make these meetings shorter it is better that people are standing.
During sprint execution it is common to find out additional tasks necessary to achieve sprint goal; to keep the control over processes during sprint development it could be useful to maintain a current '''Sprint Task List''', a '''Sprint Burndown Chart''', and an '''Impediments List''': these are some artefacts that allow developer to understand where the project is located.

===Sprint Review Meeting===
At the end of every Sprint it is held a Review meeting where the scrum team has to explain to the Product Owner what they did during the previous sprint. Usually this meeting consists in a live demonstration of the working product increment after which Product Owner states which Items can be considered as done.
Items which are declared not done have to return to the Product Backlog to be ranked and reprioritized by the Product Owner with the help of the Scrum master. Last step of this meeting is to convert stakeholders’ feedback to a new Product Log, this task is consigned to both Product Owner and Scrum Master.
The Sprint Review Meeting is the appropriate meeting for external stakeholders (even end users) to attend.

===Sprint Retrospective Meeting===
During this meeting every member of the scrum team inspects his behaviour to identify some impediments that he faced during Sprint. There are mainly three kind of impediments in which developers can be involved:
*people who conduct performance evaluation are an obstacles to transparency of the team;
*human tendency of someone in the team to jump to conclusions and propose actions too quickly;
*geographical distribution of the team can be an impediments, team work better if they are delimited in a small place like a room.<ref name='James'></ref>

After identifying all these impediments Scrum master has the task to eliminate them.

===Backlog Refinement Meeting ===
Especially at the beginning of the project "most of the Product Backlog Items (PBIs) need refinement because they are too large and poorly understood" (''M. James, 2010'')<ref name='James'></ref>. In the Backlog Refinement Meeting, the team gave an estimation of the work left to complete Items in the Product Backlog and provides other technical information to help the Product Owner prioritize them.

==Artefacts==
[[File:Product_Backlog.png|200px|thumb|right|Product Backlog<ref name='James'></ref>]]
===Product Backlog===

It is defined before the project beginning and then upgraded during the Backlog Refinement meeting ; it is made up by the whole group of items which have to be completed during the project in order to realize the final product. Every item is ranked and constantly reprioritized by the Product Owner. It is important that Product Backlog Is visible to the stakeholders.

===Product Backlog Item (PBI)===
An item specifies what has to be done but not how do it. Usually they are written in a User story to be understood also by stakeholders. Every items has a work load of 2-3 days and requires 2-3 people. It represents the basic unit of Product backlog.
[[File:Sprint_Backlog.png|200px|thumb|right|Sprint Backlog<ref name='James'></ref>]]
===Sprint backlog===

It is defined at the beginning of each sprint during the Sprint Planning meeting where committed items and the main task that have to be done during the sprint are identified. It has to be visible to Scrum team and it can be upgraded during the sprint execution with additional task necessary to achieve the final goal.

===Sprint task===
Every item is divided into several tasks, each of them requires one day or less of work. A sprint task specifies how to achieve what is required by PBI. If the task takes more than one day of work, remaining effort is re-estimated daily, typically in hours.

===Sprint Burndown Chart===
[[File:Sprint_burndown_chart.png|300px|thumb|right|Sprint Burndown Chart<ref name='James'></ref>]]
This tool is used to facilitate self-organization of the team. It indicates the total remaining team task hours within one Sprint. Usually chart shows a decreasing line but if there are some re-estimation it may be possible that line increase for then going down.

=Limitations=
Scrum method was often used in the object-oriented software development. Actually this technique are applied not only on software but also on other products from different sectors like wheelchairs, semiconductors and mortgages.
Scrum has to be used in those projects where people cannot rely on the plan-driven approaches like Waterfall, cause of unknown requirements and technology.
[[File:Graph.png|300px|thumb|right|Predictability of a Project<ref name='James'></ref>]]
Conversely if the projects is placed under precise and stable conditions it is better to use one of the traditional model which allow to have a fixed planning over the whole project. In this case Scrum method would involve in a waste of resources and money because he is working on a field that is not its responsibility.

Michael James in his “Scrum Reference card” explains with a simple graphics in which conditions Scrum should be used and which ones are not. James defines the predictability of the projects on the base of two features: knowledge of the requirements and knowledge of the level of technology required. A project which provides known requirements and a known level of technology should be carried out with a plan-driven model. It these conditions are not met it is better to use an empirical approach like Scrum.<ref name='James'></ref>

=References=
<references/>

Scrum Methodology in Agile Software Development

2015-09-27T09:29:23Z

S150821: /* Sprint Burndown Chart */

Today market is affected by uncertainly and sudden changes, in these conditions most of the models used in the 20th century to develop software are not still appropriate. Waterfall model , probably the most famous between them, is characterized by a stiff structure which can’t cope with the turbulent needs of actual market.
In recent years many innovations are been enhanced in software engineering with a particular focus on the flexibility of these methods in order to cope with the customer’s and market’s needs; surely '''Agile Software Development''' is between them.

ASD embraces the principles of lean production by applying them in software development to avoid waste and increase responsiveness to change. It represents the solution to the unpredictability of the market where the capacity to welcome change even late in development to satisfy customers is required.
This article deals with Agile Software Development with a particular focus on one of its most used technique : '''Scrum Methodology'''.

=Scrum Methodology=
Scrum is an iterative method used to develop software, it can be placed inside the group of methods which are used in '''Agile Software Development'''. This word is taken from rugby and represents that phase of the match where an ordered formation of players, with arms interlocked and heads down, push forward against a similar group to gain possession of the ball. This method provides that "work is divided into small chunks to manage complexity and to get early feedback from customers and end users" (''S. Augustine, 2005'')<ref>S. Augustine,2005,Prentice Hall PTR,Managing Agile Projects</ref>; software development is carried out by small working team that allow rapid adjustment during the process and a quick delivery of the final product.

==Agile Software Development==
Some practitioners believed that traditional iterative model was not so responsive to changes that market required. They thought that to be Agile a process needs to accept change rather than stress predictability and that methods used to develop software has to respond to change as quickly as it arose rather than prevent changes.<ref name='Cohen'>D.Cohen,M.Lindval,P. Costa,Fraunhofer Center Maryland, Agile Software Development</ref>

It was in these circumstances that practitioners as Mary Poppendieck and Bob Charet started to take inspiration from Lean manufacturing principles and apply them to software development.
These are the main points ,according to Poppendieck, which make Lean Production so successful and that can be applied to software development:

*elimination of waste that does not add value to the customer such as diagram and models that do not add value to the final deliverable;
*minimize inventory such as requirements and design documents;
*maximize flow by using iterative development to reduce development time;
*pull from demand;
*empower workers that means “tell developer what needs to be done not how to do it";
*meet customer requirements – work closely with the customer, allowing them to change their minds
*do it right the first time – test early and refactor when necessary;
*abolish local optimization – flexibly manage scope;
*partner with suppliers – avoid adversarial relationships, work towards developing the best software;
*create a culture of continuous improvement – allow the process to improve, learn from mistakes and successes.<ref name='Cohen'></ref><ref>M. Poppendieck, T. Poppendieck, 2003, Addison Wesley, Lean Software Development: An Agile Toolkit[[http://www.poppendieck.com/]]</ref>

===Manifesto for the Agile Software development===
A few years before Poppoendieck’s publication on February 2001 main principles of Agile Software development were stated by a group of 17 software developers which published “Manifesto for the Agile Software Development”.<ref>K. Beck et all., 2001, Manifesto for Agile Software Development[http://www.agilemanifesto.org/]</ref>

From reading these few words it is possible to identify what are the main innovations that ASD introduced in Software development:
[[File:Agilemanifesto.jpg|400px|thumb|right|Manifesto for the Agile Software development]]

*'''“Individuals and interactions”''' : with these words founders want to remark the power of human being creativity, and his ability to collaborate with other similar. The stiffness of Waterfall model is instead represented by “processes and tools” where people has to follow only what the plan requires.
*'''“Working software “''' : there is a clear reference to the new way to develop software where at every iteration a working program is realised, differently from the earlier model in which a working program couldn’t be seen until the end of the project. This feature is put over the “comprehensive documentation” which characterizes especially Waterfall model.
*'''“Customer collaboration”''' : means that there must be a straight relationship between customer and developer in order to define time by time the projects requirements and evaluate every realise.
*'''“Responding to change over following a plan”''' : this sentence encloses the essence of Agile software Development that is to cope with turbulent markets by being flexible and by responding quickly to change, instead of being bound by planning. This concept is remarked by the founders in one of the twelve principles which follow the manifesto which says “Welcome changing requirements, even late in development […]”.

=Application=
[[File:Scrum_Framework.png|350px|thumb|right|Scrum Framework]]
There are two concepts that are at the basement of Scrum methodology: '''iterative development''' and '''team working'''. Developing in iterations allow Scrum team to adapt quickly to changing requirements, while working in close location and focusing on communication allow team to make decisions and act on them immediately rather than wait on correspondence.<ref name='Cohen'></ref>

Basically Scrum consists in a sequence of fixed-length iterations called [[Sprint:http://apppm.man.dtu.dk/index.php?title=Scrum_Methodology_in_Agile_Software_Development&action=submit#Sprint|Sprint]] managed by one or more '''cross-functional and self-organizing teams''' each composed by seven people that aim at a common goal and that usually work only on the software development. There are instead other two figures that manage all things that are in support of the development process: one is '''Product Owner''' who mainly handles customers contacts and the other is '''Scrum Master''' whose main task is to ensure that development team can work without obstacles.

Each sprint usually lasts from 2 to 4 weeks, in this period there are at least one meeting between the Product Owner and Development Team to define the main objectives; then there are short daily meetings held every morning to enhance communication and inform customers, developers, and managers on the status of the project, identify any problems encountered, and keep the entire team focused on a common goal.<ref name='Cohen'></ref>

==Main figures in Scrum==
===Product Owner===
Product owner is the link between customers and development team, he ensures that deliverables are in line with customers’ expectation and that stakeholders’ interests are fulfilled. He has also the task to fill out customer-centric items (typically '''user stories'''), ranks and prioritizes them before adds them to '''Product Backlog'''.

Usually development teams have only one Product owner, but differently from the Scrum master, he only takes care of the business side and does not interfere with the scrum team about the technological issues. At the beginning of each Sprint the Product Owner holds a Sprint Planning Meeting to state on which Product Backlog Items Scrum team will go to work during the next Sprint. In this phase he defines what are the most important items for that business, in according to customer’s needs.

===Development Team===
Development team task is to provide Product Backlog Items (PBIs) at the end of every Sprint in according with customers’ requirements after negotiating commitments with the Product Owner.
Usually each team is composed by '''cross-functional members''' that allow an all-round software development; the main figures that there must be are a mix of software engineers, architects, programmers, analysts, QA experts, testers, and UI designers.

The size of the team is an important point, the group members' number influences capacity of people to communicate and work together: it is recommended that a scrum team is composed not more than nine people, usually seven.

Another important characteristic is the Self-organization of the group which facilitates members’ creativity and increases team cohesiveness: for this reason it is better to not change members of a team after they have worked together, especially if they had success in their project. After working together team members gain a mutual understanding that increases their capacity of team working, this synergy cannot be acquired if team are continuously changed.

A further point that characterized the good outcomes of a scrum team is location: people are most successful when located in the same room, particularly for the first few Sprints: this facilitates communication and information sharing.

====Team self-organization====
Team self-organization is a crucial point in the scrum methodology : with this concept it means that “it is told developer what needs to be done not how to do it”, they can autonomously choose the way to reach commitments.
As it is said previously during Sprint execution, team members develop an intrinsic interest in shared goals and learn to manage each other to achieve them, for this reason self-organizing teams can radically outperform larger than traditionally managed teams. It has to be specified that an optimal self-organization takes time: it may be possible that for the first few sprints developers perform worse than when they work in the traditional way.

Some requirements are necessary to gain a good team self-organization:
*members are committed to clear, short-term goals;
*members can gauge the group’s progress;
*members can observe each other’s contribution;
*members feel safe to give each other unvarnished feedback.<ref name='James'>M. James,2010,Scrum Reference Card, Michael James,[[http://scrumreferencecard.com/]]</ref>

Conversely there are some conditions that can hander self-organization:
*geographical distribution: it is better if the whole team work in a room;
*boss/work dynamics: each member has to consider the others as peer to facilitate a fair communication between them;
*part-time team members;
*interruptions unrelated to Sprint goals.

===Scrum Master===
The scrum master worries that Scrum team can work without obstacles but he has no management authority over them. Essentially he has the aim to:
*create an environment to promote team self-organization;
*support team in the achievement of expected goals;
*ensure that events (e.g. daily Scrum meeting) take place in the right way;
*keep '''Scrum artefacts''' visible ('''Product Backlog''', '''Sprint Backlog''', '''Sprint burndown chart''' …).

==Sprint==
Sprint (or iteration) is the fundamental unit in which the work is divided; it is characterized by a fixed length of 2 weeks or 30 days and by a goal to achieve. At the beginning of each sprint Scrum team , Product Owner , Scrum Master and sometimes also stakeholders hold a meeting, called Sprint Planning meeting whose output is the Sprint Backlog where goals and requirements of the next Sprint are defined. Then other meetings inside development team will be held in order to define in more detail how achieving the common goals stated in the previous meeting.
==Scrum Meetings==
[[File:Scrum_meetings.png|350px|thumb|right|Scrum Meetings<ref name='James'></ref>]]
Meeting are a fundamental tool used during the whole Scrum process. Usually they are facilitated by the Scrum master who has no decision-making authority over them . There are different typologies of meetings according to the different phase of the process in which we are.
===Sprint Planning Meeting===
At the beginning of each Sprint, the Product Owner and team hold a Sprint Planning Meeting to define on which '''Product Backlog Items (PBIs)''' they will go to work during the next Sprint. "The Product Owner is responsible for declaring which items are the most important to the business. The team is responsible for selecting the amount of work they feel they can implement" (''M. James, 2010'')<ref name='James'></ref>.In this phase in perfect Lean perspective the team “pulls” work from the Product Backlog to the Sprint Backlog. At the end of the meeting the selected items are broken into a provisional list of Sprint task. The maximum time that can be used to do Planning meeting, known as '''timebox''', is of eight hours.

===Daily Scrum and Sprint Execution===
During the sprint every day members of the Scrum team hold a fifteen minutes meeting where they take stock of the situation. Usually they speak about what they did previous day, which impediments they faced and what they are going to do in the current day. To make these meetings shorter it is better that people are standing.
During sprint execution it is common to find out additional tasks necessary to achieve sprint goal; to keep the control over processes during sprint development it could be useful to maintain a current '''Sprint Task List''', a '''Sprint Burndown Chart''', and an '''Impediments List''': these are some artefacts that allow developer to understand where the project is located.

===Sprint Review Meeting===
At the end of every Sprint it is held a Review meeting where the scrum team has to explain to the Product Owner what they did during the previous sprint. Usually this meeting consists in a live demonstration of the working product increment after which Product Owner states which Items can be considered as done.
Items which are declared not done have to return to the Product Backlog to be ranked and reprioritized by the Product Owner with the help of the Scrum master. Last step of this meeting is to convert stakeholders’ feedback to a new Product Log, this task is consigned to both Product Owner and Scrum Master.
The Sprint Review Meeting is the appropriate meeting for external stakeholders (even end users) to attend.

===Sprint Retrospective Meeting===
During this meeting every member of the scrum team inspects his behaviour to identify some impediments that he faced during Sprint. There are mainly three kind of impediments in which developers can be involved:
*people who conduct performance evaluation are an obstacles to transparency of the team;
*human tendency of someone in the team to jump to conclusions and propose actions too quickly;
*geographical distribution of the team can be an impediments, team work better if they are delimited in a small place like a room.<ref name='James'></ref>

After identifying all these impediments Scrum master has the task to eliminate them.

===Backlog Refinement Meeting ===
Especially at the beginning of the project "most of the Product Backlog Items (PBIs) need refinement because they are too large and poorly understood" (''M. James, 2010'')<ref name='James'></ref>. In the Backlog Refinement Meeting, the team gave an estimation of the work left to complete Items in the Product Backlog and provides other technical information to help the Product Owner prioritize them.

==Artefacts==
[[File:Product_Backlog.png|200px|thumb|right|Product Backlog<ref name='James'></ref>]]
===Product Backlog===

It is defined before the project beginning and then upgraded during the Backlog Refinement meeting ; it is made up by the whole group of items which have to be completed during the project in order to realize the final product. Every item is ranked and constantly reprioritized by the Product Owner. It is important that Product Backlog Is visible to the stakeholders.

===Product Backlog Item (PBI)===
An item specifies what has to be done but not how do it. Usually they are written in a User story to be understood also by stakeholders. Every items has a work load of 2-3 days and requires 2-3 people. It represents the basic unit of Product backlog.
[[File:Sprint_Backlog.png|200px|thumb|right|Sprint Backlog<ref name='James'></ref>]]
===Sprint backlog===

It is defined at the beginning of each sprint during the Sprint Planning meeting where committed items and the main task that have to be done during the sprint are identified. It has to be visible to Scrum team and it can be upgraded during the sprint execution with additional task necessary to achieve the final goal.

===Sprint task===
Every item is divided into several tasks, each of them requires one day or less of work. A sprint task specifies how to achieve what is required by PBI. If the task takes more than one day of work, remaining effort is re-estimated daily, typically in hours.

===Sprint Burndown Chart===
[[File:Sprint_burndown_chart.png|300px|thumb|right|Sprint Burndown Chart<ref name='James'></ref>]]
This tool is used to facilitate self-organization of the team. It indicates the total remaining team task hours within one Sprint. Usually chart shows a decreasing line but if there are some re-estimation it may be possible that line increase for then going down.

=Limitations=
Scrum method was often used in the object-oriented software development. Actually this technique are applied not only on software but also on other products from different sectors like wheelchairs, semiconductors and mortgages.
Scrum has to be used in those projects where people cannot rely on the plan-driven approaches like Waterfall, cause of unknown requirements and technology.
[[File:Graph.png|300px|thumb|right|Predictability of a Project]]
Conversely if the projects is placed under precise and stable conditions it is better to use one of the traditional model which allow to have a fixed planning over the whole project. In this case Scrum method would involve in a waste of resources and money because he is working on a field that is not its responsibility.

Michael James in his “Scrum Reference card” explains with a simple graphics in which conditions Scrum should be used and which ones are not. James defines the predictability of the projects on the base of two features: knowledge of the requirements and knowledge of the level of technology required. A project which provides known requirements and a known level of technology should be carried out with a plan-driven model. It these conditions are not met it is better to use an empirical approach like Scrum.<ref name='James'></ref>

=References=
<references/>

Scrum Methodology in Agile Software Development

2015-09-27T09:28:56Z

S150821: /* Artefacts */

Today market is affected by uncertainly and sudden changes, in these conditions most of the models used in the 20th century to develop software are not still appropriate. Waterfall model , probably the most famous between them, is characterized by a stiff structure which can’t cope with the turbulent needs of actual market.
In recent years many innovations are been enhanced in software engineering with a particular focus on the flexibility of these methods in order to cope with the customer’s and market’s needs; surely '''Agile Software Development''' is between them.

ASD embraces the principles of lean production by applying them in software development to avoid waste and increase responsiveness to change. It represents the solution to the unpredictability of the market where the capacity to welcome change even late in development to satisfy customers is required.
This article deals with Agile Software Development with a particular focus on one of its most used technique : '''Scrum Methodology'''.

=Scrum Methodology=
Scrum is an iterative method used to develop software, it can be placed inside the group of methods which are used in '''Agile Software Development'''. This word is taken from rugby and represents that phase of the match where an ordered formation of players, with arms interlocked and heads down, push forward against a similar group to gain possession of the ball. This method provides that "work is divided into small chunks to manage complexity and to get early feedback from customers and end users" (''S. Augustine, 2005'')<ref>S. Augustine,2005,Prentice Hall PTR,Managing Agile Projects</ref>; software development is carried out by small working team that allow rapid adjustment during the process and a quick delivery of the final product.

==Agile Software Development==
Some practitioners believed that traditional iterative model was not so responsive to changes that market required. They thought that to be Agile a process needs to accept change rather than stress predictability and that methods used to develop software has to respond to change as quickly as it arose rather than prevent changes.<ref name='Cohen'>D.Cohen,M.Lindval,P. Costa,Fraunhofer Center Maryland, Agile Software Development</ref>

It was in these circumstances that practitioners as Mary Poppendieck and Bob Charet started to take inspiration from Lean manufacturing principles and apply them to software development.
These are the main points ,according to Poppendieck, which make Lean Production so successful and that can be applied to software development:

*elimination of waste that does not add value to the customer such as diagram and models that do not add value to the final deliverable;
*minimize inventory such as requirements and design documents;
*maximize flow by using iterative development to reduce development time;
*pull from demand;
*empower workers that means “tell developer what needs to be done not how to do it";
*meet customer requirements – work closely with the customer, allowing them to change their minds
*do it right the first time – test early and refactor when necessary;
*abolish local optimization – flexibly manage scope;
*partner with suppliers – avoid adversarial relationships, work towards developing the best software;
*create a culture of continuous improvement – allow the process to improve, learn from mistakes and successes.<ref name='Cohen'></ref><ref>M. Poppendieck, T. Poppendieck, 2003, Addison Wesley, Lean Software Development: An Agile Toolkit[[http://www.poppendieck.com/]]</ref>

===Manifesto for the Agile Software development===
A few years before Poppoendieck’s publication on February 2001 main principles of Agile Software development were stated by a group of 17 software developers which published “Manifesto for the Agile Software Development”.<ref>K. Beck et all., 2001, Manifesto for Agile Software Development[http://www.agilemanifesto.org/]</ref>

From reading these few words it is possible to identify what are the main innovations that ASD introduced in Software development:
[[File:Agilemanifesto.jpg|400px|thumb|right|Manifesto for the Agile Software development]]

*'''“Individuals and interactions”''' : with these words founders want to remark the power of human being creativity, and his ability to collaborate with other similar. The stiffness of Waterfall model is instead represented by “processes and tools” where people has to follow only what the plan requires.
*'''“Working software “''' : there is a clear reference to the new way to develop software where at every iteration a working program is realised, differently from the earlier model in which a working program couldn’t be seen until the end of the project. This feature is put over the “comprehensive documentation” which characterizes especially Waterfall model.
*'''“Customer collaboration”''' : means that there must be a straight relationship between customer and developer in order to define time by time the projects requirements and evaluate every realise.
*'''“Responding to change over following a plan”''' : this sentence encloses the essence of Agile software Development that is to cope with turbulent markets by being flexible and by responding quickly to change, instead of being bound by planning. This concept is remarked by the founders in one of the twelve principles which follow the manifesto which says “Welcome changing requirements, even late in development […]”.

=Application=
[[File:Scrum_Framework.png|350px|thumb|right|Scrum Framework]]
There are two concepts that are at the basement of Scrum methodology: '''iterative development''' and '''team working'''. Developing in iterations allow Scrum team to adapt quickly to changing requirements, while working in close location and focusing on communication allow team to make decisions and act on them immediately rather than wait on correspondence.<ref name='Cohen'></ref>

Basically Scrum consists in a sequence of fixed-length iterations called [[Sprint:http://apppm.man.dtu.dk/index.php?title=Scrum_Methodology_in_Agile_Software_Development&action=submit#Sprint|Sprint]] managed by one or more '''cross-functional and self-organizing teams''' each composed by seven people that aim at a common goal and that usually work only on the software development. There are instead other two figures that manage all things that are in support of the development process: one is '''Product Owner''' who mainly handles customers contacts and the other is '''Scrum Master''' whose main task is to ensure that development team can work without obstacles.

Each sprint usually lasts from 2 to 4 weeks, in this period there are at least one meeting between the Product Owner and Development Team to define the main objectives; then there are short daily meetings held every morning to enhance communication and inform customers, developers, and managers on the status of the project, identify any problems encountered, and keep the entire team focused on a common goal.<ref name='Cohen'></ref>

==Main figures in Scrum==
===Product Owner===
Product owner is the link between customers and development team, he ensures that deliverables are in line with customers’ expectation and that stakeholders’ interests are fulfilled. He has also the task to fill out customer-centric items (typically '''user stories'''), ranks and prioritizes them before adds them to '''Product Backlog'''.

Usually development teams have only one Product owner, but differently from the Scrum master, he only takes care of the business side and does not interfere with the scrum team about the technological issues. At the beginning of each Sprint the Product Owner holds a Sprint Planning Meeting to state on which Product Backlog Items Scrum team will go to work during the next Sprint. In this phase he defines what are the most important items for that business, in according to customer’s needs.

===Development Team===
Development team task is to provide Product Backlog Items (PBIs) at the end of every Sprint in according with customers’ requirements after negotiating commitments with the Product Owner.
Usually each team is composed by '''cross-functional members''' that allow an all-round software development; the main figures that there must be are a mix of software engineers, architects, programmers, analysts, QA experts, testers, and UI designers.

The size of the team is an important point, the group members' number influences capacity of people to communicate and work together: it is recommended that a scrum team is composed not more than nine people, usually seven.

Another important characteristic is the Self-organization of the group which facilitates members’ creativity and increases team cohesiveness: for this reason it is better to not change members of a team after they have worked together, especially if they had success in their project. After working together team members gain a mutual understanding that increases their capacity of team working, this synergy cannot be acquired if team are continuously changed.

A further point that characterized the good outcomes of a scrum team is location: people are most successful when located in the same room, particularly for the first few Sprints: this facilitates communication and information sharing.

====Team self-organization====
Team self-organization is a crucial point in the scrum methodology : with this concept it means that “it is told developer what needs to be done not how to do it”, they can autonomously choose the way to reach commitments.
As it is said previously during Sprint execution, team members develop an intrinsic interest in shared goals and learn to manage each other to achieve them, for this reason self-organizing teams can radically outperform larger than traditionally managed teams. It has to be specified that an optimal self-organization takes time: it may be possible that for the first few sprints developers perform worse than when they work in the traditional way.

Some requirements are necessary to gain a good team self-organization:
*members are committed to clear, short-term goals;
*members can gauge the group’s progress;
*members can observe each other’s contribution;
*members feel safe to give each other unvarnished feedback.<ref name='James'>M. James,2010,Scrum Reference Card, Michael James,[[http://scrumreferencecard.com/]]</ref>

Conversely there are some conditions that can hander self-organization:
*geographical distribution: it is better if the whole team work in a room;
*boss/work dynamics: each member has to consider the others as peer to facilitate a fair communication between them;
*part-time team members;
*interruptions unrelated to Sprint goals.

===Scrum Master===
The scrum master worries that Scrum team can work without obstacles but he has no management authority over them. Essentially he has the aim to:
*create an environment to promote team self-organization;
*support team in the achievement of expected goals;
*ensure that events (e.g. daily Scrum meeting) take place in the right way;
*keep '''Scrum artefacts''' visible ('''Product Backlog''', '''Sprint Backlog''', '''Sprint burndown chart''' …).

==Sprint==
Sprint (or iteration) is the fundamental unit in which the work is divided; it is characterized by a fixed length of 2 weeks or 30 days and by a goal to achieve. At the beginning of each sprint Scrum team , Product Owner , Scrum Master and sometimes also stakeholders hold a meeting, called Sprint Planning meeting whose output is the Sprint Backlog where goals and requirements of the next Sprint are defined. Then other meetings inside development team will be held in order to define in more detail how achieving the common goals stated in the previous meeting.
==Scrum Meetings==
[[File:Scrum_meetings.png|350px|thumb|right|Scrum Meetings<ref name='James'></ref>]]
Meeting are a fundamental tool used during the whole Scrum process. Usually they are facilitated by the Scrum master who has no decision-making authority over them . There are different typologies of meetings according to the different phase of the process in which we are.
===Sprint Planning Meeting===
At the beginning of each Sprint, the Product Owner and team hold a Sprint Planning Meeting to define on which '''Product Backlog Items (PBIs)''' they will go to work during the next Sprint. "The Product Owner is responsible for declaring which items are the most important to the business. The team is responsible for selecting the amount of work they feel they can implement" (''M. James, 2010'')<ref name='James'></ref>.In this phase in perfect Lean perspective the team “pulls” work from the Product Backlog to the Sprint Backlog. At the end of the meeting the selected items are broken into a provisional list of Sprint task. The maximum time that can be used to do Planning meeting, known as '''timebox''', is of eight hours.

===Daily Scrum and Sprint Execution===
During the sprint every day members of the Scrum team hold a fifteen minutes meeting where they take stock of the situation. Usually they speak about what they did previous day, which impediments they faced and what they are going to do in the current day. To make these meetings shorter it is better that people are standing.
During sprint execution it is common to find out additional tasks necessary to achieve sprint goal; to keep the control over processes during sprint development it could be useful to maintain a current '''Sprint Task List''', a '''Sprint Burndown Chart''', and an '''Impediments List''': these are some artefacts that allow developer to understand where the project is located.

===Sprint Review Meeting===
At the end of every Sprint it is held a Review meeting where the scrum team has to explain to the Product Owner what they did during the previous sprint. Usually this meeting consists in a live demonstration of the working product increment after which Product Owner states which Items can be considered as done.
Items which are declared not done have to return to the Product Backlog to be ranked and reprioritized by the Product Owner with the help of the Scrum master. Last step of this meeting is to convert stakeholders’ feedback to a new Product Log, this task is consigned to both Product Owner and Scrum Master.
The Sprint Review Meeting is the appropriate meeting for external stakeholders (even end users) to attend.

===Sprint Retrospective Meeting===
During this meeting every member of the scrum team inspects his behaviour to identify some impediments that he faced during Sprint. There are mainly three kind of impediments in which developers can be involved:
*people who conduct performance evaluation are an obstacles to transparency of the team;
*human tendency of someone in the team to jump to conclusions and propose actions too quickly;
*geographical distribution of the team can be an impediments, team work better if they are delimited in a small place like a room.<ref name='James'></ref>

After identifying all these impediments Scrum master has the task to eliminate them.

===Backlog Refinement Meeting ===
Especially at the beginning of the project "most of the Product Backlog Items (PBIs) need refinement because they are too large and poorly understood" (''M. James, 2010'')<ref name='James'></ref>. In the Backlog Refinement Meeting, the team gave an estimation of the work left to complete Items in the Product Backlog and provides other technical information to help the Product Owner prioritize them.

==Artefacts==
[[File:Product_Backlog.png|200px|thumb|right|Product Backlog<ref name='James'></ref>]]
===Product Backlog===

It is defined before the project beginning and then upgraded during the Backlog Refinement meeting ; it is made up by the whole group of items which have to be completed during the project in order to realize the final product. Every item is ranked and constantly reprioritized by the Product Owner. It is important that Product Backlog Is visible to the stakeholders.

===Product Backlog Item (PBI)===
An item specifies what has to be done but not how do it. Usually they are written in a User story to be understood also by stakeholders. Every items has a work load of 2-3 days and requires 2-3 people. It represents the basic unit of Product backlog.
[[File:Sprint_Backlog.png|200px|thumb|right|Sprint Backlog<ref name='James'></ref>]]
===Sprint backlog===

It is defined at the beginning of each sprint during the Sprint Planning meeting where committed items and the main task that have to be done during the sprint are identified. It has to be visible to Scrum team and it can be upgraded during the sprint execution with additional task necessary to achieve the final goal.

===Sprint task===
Every item is divided into several tasks, each of them requires one day or less of work. A sprint task specifies how to achieve what is required by PBI. If the task takes more than one day of work, remaining effort is re-estimated daily, typically in hours.

===Sprint Burndown Chart===
[[File:Sprint_burndown_chart.png|300px|thumb|right|Sprint Burndown Chart]]
This tool is used to facilitate self-organization of the team. It indicates the total remaining team task hours within one Sprint. Usually chart shows a decreasing line but if there are some re-estimation it may be possible that line increase for then going down.

=Limitations=
Scrum method was often used in the object-oriented software development. Actually this technique are applied not only on software but also on other products from different sectors like wheelchairs, semiconductors and mortgages.
Scrum has to be used in those projects where people cannot rely on the plan-driven approaches like Waterfall, cause of unknown requirements and technology.
[[File:Graph.png|300px|thumb|right|Predictability of a Project]]
Conversely if the projects is placed under precise and stable conditions it is better to use one of the traditional model which allow to have a fixed planning over the whole project. In this case Scrum method would involve in a waste of resources and money because he is working on a field that is not its responsibility.

Michael James in his “Scrum Reference card” explains with a simple graphics in which conditions Scrum should be used and which ones are not. James defines the predictability of the projects on the base of two features: knowledge of the requirements and knowledge of the level of technology required. A project which provides known requirements and a known level of technology should be carried out with a plan-driven model. It these conditions are not met it is better to use an empirical approach like Scrum.<ref name='James'></ref>

=References=
<references/>

Scrum Methodology in Agile Software Development

2015-09-27T09:28:21Z

S150821: /* Scrum Meetings */

Today market is affected by uncertainly and sudden changes, in these conditions most of the models used in the 20th century to develop software are not still appropriate. Waterfall model , probably the most famous between them, is characterized by a stiff structure which can’t cope with the turbulent needs of actual market.
In recent years many innovations are been enhanced in software engineering with a particular focus on the flexibility of these methods in order to cope with the customer’s and market’s needs; surely '''Agile Software Development''' is between them.

ASD embraces the principles of lean production by applying them in software development to avoid waste and increase responsiveness to change. It represents the solution to the unpredictability of the market where the capacity to welcome change even late in development to satisfy customers is required.
This article deals with Agile Software Development with a particular focus on one of its most used technique : '''Scrum Methodology'''.

=Scrum Methodology=
Scrum is an iterative method used to develop software, it can be placed inside the group of methods which are used in '''Agile Software Development'''. This word is taken from rugby and represents that phase of the match where an ordered formation of players, with arms interlocked and heads down, push forward against a similar group to gain possession of the ball. This method provides that "work is divided into small chunks to manage complexity and to get early feedback from customers and end users" (''S. Augustine, 2005'')<ref>S. Augustine,2005,Prentice Hall PTR,Managing Agile Projects</ref>; software development is carried out by small working team that allow rapid adjustment during the process and a quick delivery of the final product.

==Agile Software Development==
Some practitioners believed that traditional iterative model was not so responsive to changes that market required. They thought that to be Agile a process needs to accept change rather than stress predictability and that methods used to develop software has to respond to change as quickly as it arose rather than prevent changes.<ref name='Cohen'>D.Cohen,M.Lindval,P. Costa,Fraunhofer Center Maryland, Agile Software Development</ref>

It was in these circumstances that practitioners as Mary Poppendieck and Bob Charet started to take inspiration from Lean manufacturing principles and apply them to software development.
These are the main points ,according to Poppendieck, which make Lean Production so successful and that can be applied to software development:

*elimination of waste that does not add value to the customer such as diagram and models that do not add value to the final deliverable;
*minimize inventory such as requirements and design documents;
*maximize flow by using iterative development to reduce development time;
*pull from demand;
*empower workers that means “tell developer what needs to be done not how to do it";
*meet customer requirements – work closely with the customer, allowing them to change their minds
*do it right the first time – test early and refactor when necessary;
*abolish local optimization – flexibly manage scope;
*partner with suppliers – avoid adversarial relationships, work towards developing the best software;
*create a culture of continuous improvement – allow the process to improve, learn from mistakes and successes.<ref name='Cohen'></ref><ref>M. Poppendieck, T. Poppendieck, 2003, Addison Wesley, Lean Software Development: An Agile Toolkit[[http://www.poppendieck.com/]]</ref>

===Manifesto for the Agile Software development===
A few years before Poppoendieck’s publication on February 2001 main principles of Agile Software development were stated by a group of 17 software developers which published “Manifesto for the Agile Software Development”.<ref>K. Beck et all., 2001, Manifesto for Agile Software Development[http://www.agilemanifesto.org/]</ref>

From reading these few words it is possible to identify what are the main innovations that ASD introduced in Software development:
[[File:Agilemanifesto.jpg|400px|thumb|right|Manifesto for the Agile Software development]]

*'''“Individuals and interactions”''' : with these words founders want to remark the power of human being creativity, and his ability to collaborate with other similar. The stiffness of Waterfall model is instead represented by “processes and tools” where people has to follow only what the plan requires.
*'''“Working software “''' : there is a clear reference to the new way to develop software where at every iteration a working program is realised, differently from the earlier model in which a working program couldn’t be seen until the end of the project. This feature is put over the “comprehensive documentation” which characterizes especially Waterfall model.
*'''“Customer collaboration”''' : means that there must be a straight relationship between customer and developer in order to define time by time the projects requirements and evaluate every realise.
*'''“Responding to change over following a plan”''' : this sentence encloses the essence of Agile software Development that is to cope with turbulent markets by being flexible and by responding quickly to change, instead of being bound by planning. This concept is remarked by the founders in one of the twelve principles which follow the manifesto which says “Welcome changing requirements, even late in development […]”.

=Application=
[[File:Scrum_Framework.png|350px|thumb|right|Scrum Framework]]
There are two concepts that are at the basement of Scrum methodology: '''iterative development''' and '''team working'''. Developing in iterations allow Scrum team to adapt quickly to changing requirements, while working in close location and focusing on communication allow team to make decisions and act on them immediately rather than wait on correspondence.<ref name='Cohen'></ref>

Basically Scrum consists in a sequence of fixed-length iterations called [[Sprint:http://apppm.man.dtu.dk/index.php?title=Scrum_Methodology_in_Agile_Software_Development&action=submit#Sprint|Sprint]] managed by one or more '''cross-functional and self-organizing teams''' each composed by seven people that aim at a common goal and that usually work only on the software development. There are instead other two figures that manage all things that are in support of the development process: one is '''Product Owner''' who mainly handles customers contacts and the other is '''Scrum Master''' whose main task is to ensure that development team can work without obstacles.

Each sprint usually lasts from 2 to 4 weeks, in this period there are at least one meeting between the Product Owner and Development Team to define the main objectives; then there are short daily meetings held every morning to enhance communication and inform customers, developers, and managers on the status of the project, identify any problems encountered, and keep the entire team focused on a common goal.<ref name='Cohen'></ref>

==Main figures in Scrum==
===Product Owner===
Product owner is the link between customers and development team, he ensures that deliverables are in line with customers’ expectation and that stakeholders’ interests are fulfilled. He has also the task to fill out customer-centric items (typically '''user stories'''), ranks and prioritizes them before adds them to '''Product Backlog'''.

Usually development teams have only one Product owner, but differently from the Scrum master, he only takes care of the business side and does not interfere with the scrum team about the technological issues. At the beginning of each Sprint the Product Owner holds a Sprint Planning Meeting to state on which Product Backlog Items Scrum team will go to work during the next Sprint. In this phase he defines what are the most important items for that business, in according to customer’s needs.

===Development Team===
Development team task is to provide Product Backlog Items (PBIs) at the end of every Sprint in according with customers’ requirements after negotiating commitments with the Product Owner.
Usually each team is composed by '''cross-functional members''' that allow an all-round software development; the main figures that there must be are a mix of software engineers, architects, programmers, analysts, QA experts, testers, and UI designers.

The size of the team is an important point, the group members' number influences capacity of people to communicate and work together: it is recommended that a scrum team is composed not more than nine people, usually seven.

Another important characteristic is the Self-organization of the group which facilitates members’ creativity and increases team cohesiveness: for this reason it is better to not change members of a team after they have worked together, especially if they had success in their project. After working together team members gain a mutual understanding that increases their capacity of team working, this synergy cannot be acquired if team are continuously changed.

A further point that characterized the good outcomes of a scrum team is location: people are most successful when located in the same room, particularly for the first few Sprints: this facilitates communication and information sharing.

====Team self-organization====
Team self-organization is a crucial point in the scrum methodology : with this concept it means that “it is told developer what needs to be done not how to do it”, they can autonomously choose the way to reach commitments.
As it is said previously during Sprint execution, team members develop an intrinsic interest in shared goals and learn to manage each other to achieve them, for this reason self-organizing teams can radically outperform larger than traditionally managed teams. It has to be specified that an optimal self-organization takes time: it may be possible that for the first few sprints developers perform worse than when they work in the traditional way.

Some requirements are necessary to gain a good team self-organization:
*members are committed to clear, short-term goals;
*members can gauge the group’s progress;
*members can observe each other’s contribution;
*members feel safe to give each other unvarnished feedback.<ref name='James'>M. James,2010,Scrum Reference Card, Michael James,[[http://scrumreferencecard.com/]]</ref>

Conversely there are some conditions that can hander self-organization:
*geographical distribution: it is better if the whole team work in a room;
*boss/work dynamics: each member has to consider the others as peer to facilitate a fair communication between them;
*part-time team members;
*interruptions unrelated to Sprint goals.

===Scrum Master===
The scrum master worries that Scrum team can work without obstacles but he has no management authority over them. Essentially he has the aim to:
*create an environment to promote team self-organization;
*support team in the achievement of expected goals;
*ensure that events (e.g. daily Scrum meeting) take place in the right way;
*keep '''Scrum artefacts''' visible ('''Product Backlog''', '''Sprint Backlog''', '''Sprint burndown chart''' …).

==Sprint==
Sprint (or iteration) is the fundamental unit in which the work is divided; it is characterized by a fixed length of 2 weeks or 30 days and by a goal to achieve. At the beginning of each sprint Scrum team , Product Owner , Scrum Master and sometimes also stakeholders hold a meeting, called Sprint Planning meeting whose output is the Sprint Backlog where goals and requirements of the next Sprint are defined. Then other meetings inside development team will be held in order to define in more detail how achieving the common goals stated in the previous meeting.
==Scrum Meetings==
[[File:Scrum_meetings.png|350px|thumb|right|Scrum Meetings<ref name='James'></ref>]]
Meeting are a fundamental tool used during the whole Scrum process. Usually they are facilitated by the Scrum master who has no decision-making authority over them . There are different typologies of meetings according to the different phase of the process in which we are.
===Sprint Planning Meeting===
At the beginning of each Sprint, the Product Owner and team hold a Sprint Planning Meeting to define on which '''Product Backlog Items (PBIs)''' they will go to work during the next Sprint. "The Product Owner is responsible for declaring which items are the most important to the business. The team is responsible for selecting the amount of work they feel they can implement" (''M. James, 2010'')<ref name='James'></ref>.In this phase in perfect Lean perspective the team “pulls” work from the Product Backlog to the Sprint Backlog. At the end of the meeting the selected items are broken into a provisional list of Sprint task. The maximum time that can be used to do Planning meeting, known as '''timebox''', is of eight hours.

===Daily Scrum and Sprint Execution===
During the sprint every day members of the Scrum team hold a fifteen minutes meeting where they take stock of the situation. Usually they speak about what they did previous day, which impediments they faced and what they are going to do in the current day. To make these meetings shorter it is better that people are standing.
During sprint execution it is common to find out additional tasks necessary to achieve sprint goal; to keep the control over processes during sprint development it could be useful to maintain a current '''Sprint Task List''', a '''Sprint Burndown Chart''', and an '''Impediments List''': these are some artefacts that allow developer to understand where the project is located.

===Sprint Review Meeting===
At the end of every Sprint it is held a Review meeting where the scrum team has to explain to the Product Owner what they did during the previous sprint. Usually this meeting consists in a live demonstration of the working product increment after which Product Owner states which Items can be considered as done.
Items which are declared not done have to return to the Product Backlog to be ranked and reprioritized by the Product Owner with the help of the Scrum master. Last step of this meeting is to convert stakeholders’ feedback to a new Product Log, this task is consigned to both Product Owner and Scrum Master.
The Sprint Review Meeting is the appropriate meeting for external stakeholders (even end users) to attend.

===Sprint Retrospective Meeting===
During this meeting every member of the scrum team inspects his behaviour to identify some impediments that he faced during Sprint. There are mainly three kind of impediments in which developers can be involved:
*people who conduct performance evaluation are an obstacles to transparency of the team;
*human tendency of someone in the team to jump to conclusions and propose actions too quickly;
*geographical distribution of the team can be an impediments, team work better if they are delimited in a small place like a room.<ref name='James'></ref>

After identifying all these impediments Scrum master has the task to eliminate them.

===Backlog Refinement Meeting ===
Especially at the beginning of the project "most of the Product Backlog Items (PBIs) need refinement because they are too large and poorly understood" (''M. James, 2010'')<ref name='James'></ref>. In the Backlog Refinement Meeting, the team gave an estimation of the work left to complete Items in the Product Backlog and provides other technical information to help the Product Owner prioritize them.

==Artefacts==
[[File:Product_Backlog.png|200px|thumb|right|Product Backlog]]
===Product Backlog===

It is defined before the project beginning and then upgraded during the Backlog Refinement meeting ; it is made up by the whole group of items which have to be completed during the project in order to realize the final product. Every item is ranked and constantly reprioritized by the Product Owner. It is important that Product Backlog Is visible to the stakeholders.

===Product Backlog Item (PBI)===
An item specifies what has to be done but not how do it. Usually they are written in a User story to be understood also by stakeholders. Every items has a work load of 2-3 days and requires 2-3 people. It represents the basic unit of Product backlog.
[[File:Sprint_Backlog.png|200px|thumb|right|Sprint Backlog]]
===Sprint backlog===

It is defined at the beginning of each sprint during the Sprint Planning meeting where committed items and the main task that have to be done during the sprint are identified. It has to be visible to Scrum team and it can be upgraded during the sprint execution with additional task necessary to achieve the final goal.

===Sprint task===
Every item is divided into several tasks, each of them requires one day or less of work. A sprint task specifies how to achieve what is required by PBI. If the task takes more than one day of work, remaining effort is re-estimated daily, typically in hours.

===Sprint Burndown Chart===
[[File:Sprint_burndown_chart.png|300px|thumb|right|Sprint Burndown Chart]]
This tool is used to facilitate self-organization of the team. It indicates the total remaining team task hours within one Sprint. Usually chart shows a decreasing line but if there are some re-estimation it may be possible that line increase for then going down.

=Limitations=
Scrum method was often used in the object-oriented software development. Actually this technique are applied not only on software but also on other products from different sectors like wheelchairs, semiconductors and mortgages.
Scrum has to be used in those projects where people cannot rely on the plan-driven approaches like Waterfall, cause of unknown requirements and technology.
[[File:Graph.png|300px|thumb|right|Predictability of a Project]]
Conversely if the projects is placed under precise and stable conditions it is better to use one of the traditional model which allow to have a fixed planning over the whole project. In this case Scrum method would involve in a waste of resources and money because he is working on a field that is not its responsibility.

Michael James in his “Scrum Reference card” explains with a simple graphics in which conditions Scrum should be used and which ones are not. James defines the predictability of the projects on the base of two features: knowledge of the requirements and knowledge of the level of technology required. A project which provides known requirements and a known level of technology should be carried out with a plan-driven model. It these conditions are not met it is better to use an empirical approach like Scrum.<ref name='James'></ref>

=References=
<references/>

Scrum Methodology in Agile Software Development

2015-09-27T09:24:13Z

S150821: /* Sprint Planning Meeting */

Today market is affected by uncertainly and sudden changes, in these conditions most of the models used in the 20th century to develop software are not still appropriate. Waterfall model , probably the most famous between them, is characterized by a stiff structure which can’t cope with the turbulent needs of actual market.
In recent years many innovations are been enhanced in software engineering with a particular focus on the flexibility of these methods in order to cope with the customer’s and market’s needs; surely '''Agile Software Development''' is between them.

ASD embraces the principles of lean production by applying them in software development to avoid waste and increase responsiveness to change. It represents the solution to the unpredictability of the market where the capacity to welcome change even late in development to satisfy customers is required.
This article deals with Agile Software Development with a particular focus on one of its most used technique : '''Scrum Methodology'''.

=Scrum Methodology=
Scrum is an iterative method used to develop software, it can be placed inside the group of methods which are used in '''Agile Software Development'''. This word is taken from rugby and represents that phase of the match where an ordered formation of players, with arms interlocked and heads down, push forward against a similar group to gain possession of the ball. This method provides that "work is divided into small chunks to manage complexity and to get early feedback from customers and end users" (''S. Augustine, 2005'')<ref>S. Augustine,2005,Prentice Hall PTR,Managing Agile Projects</ref>; software development is carried out by small working team that allow rapid adjustment during the process and a quick delivery of the final product.

==Agile Software Development==
Some practitioners believed that traditional iterative model was not so responsive to changes that market required. They thought that to be Agile a process needs to accept change rather than stress predictability and that methods used to develop software has to respond to change as quickly as it arose rather than prevent changes.<ref name='Cohen'>D.Cohen,M.Lindval,P. Costa,Fraunhofer Center Maryland, Agile Software Development</ref>

It was in these circumstances that practitioners as Mary Poppendieck and Bob Charet started to take inspiration from Lean manufacturing principles and apply them to software development.
These are the main points ,according to Poppendieck, which make Lean Production so successful and that can be applied to software development:

*elimination of waste that does not add value to the customer such as diagram and models that do not add value to the final deliverable;
*minimize inventory such as requirements and design documents;
*maximize flow by using iterative development to reduce development time;
*pull from demand;
*empower workers that means “tell developer what needs to be done not how to do it";
*meet customer requirements – work closely with the customer, allowing them to change their minds
*do it right the first time – test early and refactor when necessary;
*abolish local optimization – flexibly manage scope;
*partner with suppliers – avoid adversarial relationships, work towards developing the best software;
*create a culture of continuous improvement – allow the process to improve, learn from mistakes and successes.<ref name='Cohen'></ref><ref>M. Poppendieck, T. Poppendieck, 2003, Addison Wesley, Lean Software Development: An Agile Toolkit[[http://www.poppendieck.com/]]</ref>

===Manifesto for the Agile Software development===
A few years before Poppoendieck’s publication on February 2001 main principles of Agile Software development were stated by a group of 17 software developers which published “Manifesto for the Agile Software Development”.<ref>K. Beck et all., 2001, Manifesto for Agile Software Development[http://www.agilemanifesto.org/]</ref>

From reading these few words it is possible to identify what are the main innovations that ASD introduced in Software development:
[[File:Agilemanifesto.jpg|400px|thumb|right|Manifesto for the Agile Software development]]

*'''“Individuals and interactions”''' : with these words founders want to remark the power of human being creativity, and his ability to collaborate with other similar. The stiffness of Waterfall model is instead represented by “processes and tools” where people has to follow only what the plan requires.
*'''“Working software “''' : there is a clear reference to the new way to develop software where at every iteration a working program is realised, differently from the earlier model in which a working program couldn’t be seen until the end of the project. This feature is put over the “comprehensive documentation” which characterizes especially Waterfall model.
*'''“Customer collaboration”''' : means that there must be a straight relationship between customer and developer in order to define time by time the projects requirements and evaluate every realise.
*'''“Responding to change over following a plan”''' : this sentence encloses the essence of Agile software Development that is to cope with turbulent markets by being flexible and by responding quickly to change, instead of being bound by planning. This concept is remarked by the founders in one of the twelve principles which follow the manifesto which says “Welcome changing requirements, even late in development […]”.

=Application=
[[File:Scrum_Framework.png|350px|thumb|right|Scrum Framework]]
There are two concepts that are at the basement of Scrum methodology: '''iterative development''' and '''team working'''. Developing in iterations allow Scrum team to adapt quickly to changing requirements, while working in close location and focusing on communication allow team to make decisions and act on them immediately rather than wait on correspondence.<ref name='Cohen'></ref>

Basically Scrum consists in a sequence of fixed-length iterations called [[Sprint:http://apppm.man.dtu.dk/index.php?title=Scrum_Methodology_in_Agile_Software_Development&action=submit#Sprint|Sprint]] managed by one or more '''cross-functional and self-organizing teams''' each composed by seven people that aim at a common goal and that usually work only on the software development. There are instead other two figures that manage all things that are in support of the development process: one is '''Product Owner''' who mainly handles customers contacts and the other is '''Scrum Master''' whose main task is to ensure that development team can work without obstacles.

Each sprint usually lasts from 2 to 4 weeks, in this period there are at least one meeting between the Product Owner and Development Team to define the main objectives; then there are short daily meetings held every morning to enhance communication and inform customers, developers, and managers on the status of the project, identify any problems encountered, and keep the entire team focused on a common goal.<ref name='Cohen'></ref>

==Main figures in Scrum==
===Product Owner===
Product owner is the link between customers and development team, he ensures that deliverables are in line with customers’ expectation and that stakeholders’ interests are fulfilled. He has also the task to fill out customer-centric items (typically '''user stories'''), ranks and prioritizes them before adds them to '''Product Backlog'''.

Usually development teams have only one Product owner, but differently from the Scrum master, he only takes care of the business side and does not interfere with the scrum team about the technological issues. At the beginning of each Sprint the Product Owner holds a Sprint Planning Meeting to state on which Product Backlog Items Scrum team will go to work during the next Sprint. In this phase he defines what are the most important items for that business, in according to customer’s needs.

===Development Team===
Development team task is to provide Product Backlog Items (PBIs) at the end of every Sprint in according with customers’ requirements after negotiating commitments with the Product Owner.
Usually each team is composed by '''cross-functional members''' that allow an all-round software development; the main figures that there must be are a mix of software engineers, architects, programmers, analysts, QA experts, testers, and UI designers.

The size of the team is an important point, the group members' number influences capacity of people to communicate and work together: it is recommended that a scrum team is composed not more than nine people, usually seven.

Another important characteristic is the Self-organization of the group which facilitates members’ creativity and increases team cohesiveness: for this reason it is better to not change members of a team after they have worked together, especially if they had success in their project. After working together team members gain a mutual understanding that increases their capacity of team working, this synergy cannot be acquired if team are continuously changed.

A further point that characterized the good outcomes of a scrum team is location: people are most successful when located in the same room, particularly for the first few Sprints: this facilitates communication and information sharing.

====Team self-organization====
Team self-organization is a crucial point in the scrum methodology : with this concept it means that “it is told developer what needs to be done not how to do it”, they can autonomously choose the way to reach commitments.
As it is said previously during Sprint execution, team members develop an intrinsic interest in shared goals and learn to manage each other to achieve them, for this reason self-organizing teams can radically outperform larger than traditionally managed teams. It has to be specified that an optimal self-organization takes time: it may be possible that for the first few sprints developers perform worse than when they work in the traditional way.

Some requirements are necessary to gain a good team self-organization:
*members are committed to clear, short-term goals;
*members can gauge the group’s progress;
*members can observe each other’s contribution;
*members feel safe to give each other unvarnished feedback.<ref name='James'>M. James,2010,Scrum Reference Card, Michael James,[[http://scrumreferencecard.com/]]</ref>

Conversely there are some conditions that can hander self-organization:
*geographical distribution: it is better if the whole team work in a room;
*boss/work dynamics: each member has to consider the others as peer to facilitate a fair communication between them;
*part-time team members;
*interruptions unrelated to Sprint goals.

===Scrum Master===
The scrum master worries that Scrum team can work without obstacles but he has no management authority over them. Essentially he has the aim to:
*create an environment to promote team self-organization;
*support team in the achievement of expected goals;
*ensure that events (e.g. daily Scrum meeting) take place in the right way;
*keep '''Scrum artefacts''' visible ('''Product Backlog''', '''Sprint Backlog''', '''Sprint burndown chart''' …).

==Sprint==
Sprint (or iteration) is the fundamental unit in which the work is divided; it is characterized by a fixed length of 2 weeks or 30 days and by a goal to achieve. At the beginning of each sprint Scrum team , Product Owner , Scrum Master and sometimes also stakeholders hold a meeting, called Sprint Planning meeting whose output is the Sprint Backlog where goals and requirements of the next Sprint are defined. Then other meetings inside development team will be held in order to define in more detail how achieving the common goals stated in the previous meeting.
==Scrum Meetings==
[[File:Scrum_meetings.png|350px|thumb|right|Scrum Meetings]]
Meeting are a fundamental tool used during the whole Scrum process. Usually they are facilitated by the Scrum master who has no decision-making authority over them . There are different typologies of meetings according to the different phase of the process in which we are.
===Sprint Planning Meeting===
At the beginning of each Sprint, the Product Owner and team hold a Sprint Planning Meeting to define on which '''Product Backlog Items (PBIs)''' they will go to work during the next Sprint. "The Product Owner is responsible for declaring which items are the most important to the business. The team is responsible for selecting the amount of work they feel they can implement" (''M. James, 2010'')<ref name='James'></ref>.In this phase in perfect Lean perspective the team “pulls” work from the Product Backlog to the Sprint Backlog. At the end of the meeting the selected items are broken into a provisional list of Sprint task. The maximum time that can be used to do Planning meeting, known as '''timebox''', is of eight hours.

===Daily Scrum and Sprint Execution===
During the sprint every day members of the Scrum team hold a fifteen minutes meeting where they take stock of the situation. Usually they speak about what they did previous day, which impediments they faced and what they are going to do in the current day. To make these meetings shorter it is better that people are standing.
During sprint execution it is common to find out additional tasks necessary to achieve sprint goal; to keep the control over processes during sprint development it could be useful to maintain a current '''Sprint Task List''', a '''Sprint Burndown Chart''', and an '''Impediments List''': these are some artefacts that allow developer to understand where the project is located.

===Sprint Review Meeting===
At the end of every Sprint it is held a Review meeting where the scrum team has to explain to the Product Owner what they did during the previous sprint. Usually this meeting consists in a live demonstration of the working product increment after which Product Owner states which Items can be considered as done.
Items which are declared not done have to return to the Product Backlog to be ranked and reprioritized by the Product Owner with the help of the Scrum master. Last step of this meeting is to convert stakeholders’ feedback to a new Product Log, this task is consigned to both Product Owner and Scrum Master.
The Sprint Review Meeting is the appropriate meeting for external stakeholders (even end users) to attend.

===Sprint Retrospective Meeting===
During this meeting every member of the scrum team inspects his behaviour to identify some impediments that he faced during Sprint. There are mainly three kind of impediments in which developers can be involved:
*people who conduct performance evaluation are an obstacles to transparency of the team;
*human tendency of someone in the team to jump to conclusions and propose actions too quickly;
*geographical distribution of the team can be an impediments, team work better if they are delimited in a small place like a room.<ref name='James'></ref>

After identifying all these impediments Scrum master has the task to eliminate them.

===Backlog Refinement Meeting ===
Especially at the beginning of the project "most of the Product Backlog Items (PBIs) need refinement because they are too large and poorly understood" (''M. James, 2010'')<ref name='James'></ref>. In the Backlog Refinement Meeting, the team gave an estimation of the work left to complete Items in the Product Backlog and provides other technical information to help the Product Owner prioritize them.

==Artefacts==
[[File:Product_Backlog.png|200px|thumb|right|Product Backlog]]
===Product Backlog===

It is defined before the project beginning and then upgraded during the Backlog Refinement meeting ; it is made up by the whole group of items which have to be completed during the project in order to realize the final product. Every item is ranked and constantly reprioritized by the Product Owner. It is important that Product Backlog Is visible to the stakeholders.

===Product Backlog Item (PBI)===
An item specifies what has to be done but not how do it. Usually they are written in a User story to be understood also by stakeholders. Every items has a work load of 2-3 days and requires 2-3 people. It represents the basic unit of Product backlog.
[[File:Sprint_Backlog.png|200px|thumb|right|Sprint Backlog]]
===Sprint backlog===

It is defined at the beginning of each sprint during the Sprint Planning meeting where committed items and the main task that have to be done during the sprint are identified. It has to be visible to Scrum team and it can be upgraded during the sprint execution with additional task necessary to achieve the final goal.

===Sprint task===
Every item is divided into several tasks, each of them requires one day or less of work. A sprint task specifies how to achieve what is required by PBI. If the task takes more than one day of work, remaining effort is re-estimated daily, typically in hours.

===Sprint Burndown Chart===
[[File:Sprint_burndown_chart.png|300px|thumb|right|Sprint Burndown Chart]]
This tool is used to facilitate self-organization of the team. It indicates the total remaining team task hours within one Sprint. Usually chart shows a decreasing line but if there are some re-estimation it may be possible that line increase for then going down.

=Limitations=
Scrum method was often used in the object-oriented software development. Actually this technique are applied not only on software but also on other products from different sectors like wheelchairs, semiconductors and mortgages.
Scrum has to be used in those projects where people cannot rely on the plan-driven approaches like Waterfall, cause of unknown requirements and technology.
[[File:Graph.png|300px|thumb|right|Predictability of a Project]]
Conversely if the projects is placed under precise and stable conditions it is better to use one of the traditional model which allow to have a fixed planning over the whole project. In this case Scrum method would involve in a waste of resources and money because he is working on a field that is not its responsibility.

Michael James in his “Scrum Reference card” explains with a simple graphics in which conditions Scrum should be used and which ones are not. James defines the predictability of the projects on the base of two features: knowledge of the requirements and knowledge of the level of technology required. A project which provides known requirements and a known level of technology should be carried out with a plan-driven model. It these conditions are not met it is better to use an empirical approach like Scrum.<ref name='James'></ref>

=References=
<references/>

Scrum Methodology in Agile Software Development

2015-09-27T09:10:21Z

S150821: /* Application */

Today market is affected by uncertainly and sudden changes, in these conditions most of the models used in the 20th century to develop software are not still appropriate. Waterfall model , probably the most famous between them, is characterized by a stiff structure which can’t cope with the turbulent needs of actual market.
In recent years many innovations are been enhanced in software engineering with a particular focus on the flexibility of these methods in order to cope with the customer’s and market’s needs; surely '''Agile Software Development''' is between them.

ASD embraces the principles of lean production by applying them in software development to avoid waste and increase responsiveness to change. It represents the solution to the unpredictability of the market where the capacity to welcome change even late in development to satisfy customers is required.
This article deals with Agile Software Development with a particular focus on one of its most used technique : '''Scrum Methodology'''.

=Scrum Methodology=
Scrum is an iterative method used to develop software, it can be placed inside the group of methods which are used in '''Agile Software Development'''. This word is taken from rugby and represents that phase of the match where an ordered formation of players, with arms interlocked and heads down, push forward against a similar group to gain possession of the ball. This method provides that "work is divided into small chunks to manage complexity and to get early feedback from customers and end users" (''S. Augustine, 2005'')<ref>S. Augustine,2005,Prentice Hall PTR,Managing Agile Projects</ref>; software development is carried out by small working team that allow rapid adjustment during the process and a quick delivery of the final product.

==Agile Software Development==
Some practitioners believed that traditional iterative model was not so responsive to changes that market required. They thought that to be Agile a process needs to accept change rather than stress predictability and that methods used to develop software has to respond to change as quickly as it arose rather than prevent changes.<ref name='Cohen'>D.Cohen,M.Lindval,P. Costa,Fraunhofer Center Maryland, Agile Software Development</ref>

It was in these circumstances that practitioners as Mary Poppendieck and Bob Charet started to take inspiration from Lean manufacturing principles and apply them to software development.
These are the main points ,according to Poppendieck, which make Lean Production so successful and that can be applied to software development:

*elimination of waste that does not add value to the customer such as diagram and models that do not add value to the final deliverable;
*minimize inventory such as requirements and design documents;
*maximize flow by using iterative development to reduce development time;
*pull from demand;
*empower workers that means “tell developer what needs to be done not how to do it";
*meet customer requirements – work closely with the customer, allowing them to change their minds
*do it right the first time – test early and refactor when necessary;
*abolish local optimization – flexibly manage scope;
*partner with suppliers – avoid adversarial relationships, work towards developing the best software;
*create a culture of continuous improvement – allow the process to improve, learn from mistakes and successes.<ref name='Cohen'></ref><ref>M. Poppendieck, T. Poppendieck, 2003, Addison Wesley, Lean Software Development: An Agile Toolkit[[http://www.poppendieck.com/]]</ref>

===Manifesto for the Agile Software development===
A few years before Poppoendieck’s publication on February 2001 main principles of Agile Software development were stated by a group of 17 software developers which published “Manifesto for the Agile Software Development”.<ref>K. Beck et all., 2001, Manifesto for Agile Software Development[http://www.agilemanifesto.org/]</ref>

From reading these few words it is possible to identify what are the main innovations that ASD introduced in Software development:
[[File:Agilemanifesto.jpg|400px|thumb|right|Manifesto for the Agile Software development]]

*'''“Individuals and interactions”''' : with these words founders want to remark the power of human being creativity, and his ability to collaborate with other similar. The stiffness of Waterfall model is instead represented by “processes and tools” where people has to follow only what the plan requires.
*'''“Working software “''' : there is a clear reference to the new way to develop software where at every iteration a working program is realised, differently from the earlier model in which a working program couldn’t be seen until the end of the project. This feature is put over the “comprehensive documentation” which characterizes especially Waterfall model.
*'''“Customer collaboration”''' : means that there must be a straight relationship between customer and developer in order to define time by time the projects requirements and evaluate every realise.
*'''“Responding to change over following a plan”''' : this sentence encloses the essence of Agile software Development that is to cope with turbulent markets by being flexible and by responding quickly to change, instead of being bound by planning. This concept is remarked by the founders in one of the twelve principles which follow the manifesto which says “Welcome changing requirements, even late in development […]”.

=Application=
[[File:Scrum_Framework.png|350px|thumb|right|Scrum Framework]]
There are two concepts that are at the basement of Scrum methodology: '''iterative development''' and '''team working'''. Developing in iterations allow Scrum team to adapt quickly to changing requirements, while working in close location and focusing on communication allow team to make decisions and act on them immediately rather than wait on correspondence.<ref name='Cohen'></ref>

Basically Scrum consists in a sequence of fixed-length iterations called [[Sprint:http://apppm.man.dtu.dk/index.php?title=Scrum_Methodology_in_Agile_Software_Development&action=submit#Sprint|Sprint]] managed by one or more '''cross-functional and self-organizing teams''' each composed by seven people that aim at a common goal and that usually work only on the software development. There are instead other two figures that manage all things that are in support of the development process: one is '''Product Owner''' who mainly handles customers contacts and the other is '''Scrum Master''' whose main task is to ensure that development team can work without obstacles.

Each sprint usually lasts from 2 to 4 weeks, in this period there are at least one meeting between the Product Owner and Development Team to define the main objectives; then there are short daily meetings held every morning to enhance communication and inform customers, developers, and managers on the status of the project, identify any problems encountered, and keep the entire team focused on a common goal.<ref name='Cohen'></ref>

==Main figures in Scrum==
===Product Owner===
Product owner is the link between customers and development team, he ensures that deliverables are in line with customers’ expectation and that stakeholders’ interests are fulfilled. He has also the task to fill out customer-centric items (typically '''user stories'''), ranks and prioritizes them before adds them to '''Product Backlog'''.

Usually development teams have only one Product owner, but differently from the Scrum master, he only takes care of the business side and does not interfere with the scrum team about the technological issues. At the beginning of each Sprint the Product Owner holds a Sprint Planning Meeting to state on which Product Backlog Items Scrum team will go to work during the next Sprint. In this phase he defines what are the most important items for that business, in according to customer’s needs.

===Development Team===
Development team task is to provide Product Backlog Items (PBIs) at the end of every Sprint in according with customers’ requirements after negotiating commitments with the Product Owner.
Usually each team is composed by '''cross-functional members''' that allow an all-round software development; the main figures that there must be are a mix of software engineers, architects, programmers, analysts, QA experts, testers, and UI designers.

The size of the team is an important point, the group members' number influences capacity of people to communicate and work together: it is recommended that a scrum team is composed not more than nine people, usually seven.

Another important characteristic is the Self-organization of the group which facilitates members’ creativity and increases team cohesiveness: for this reason it is better to not change members of a team after they have worked together, especially if they had success in their project. After working together team members gain a mutual understanding that increases their capacity of team working, this synergy cannot be acquired if team are continuously changed.

A further point that characterized the good outcomes of a scrum team is location: people are most successful when located in the same room, particularly for the first few Sprints: this facilitates communication and information sharing.

====Team self-organization====
Team self-organization is a crucial point in the scrum methodology : with this concept it means that “it is told developer what needs to be done not how to do it”, they can autonomously choose the way to reach commitments.
As it is said previously during Sprint execution, team members develop an intrinsic interest in shared goals and learn to manage each other to achieve them, for this reason self-organizing teams can radically outperform larger than traditionally managed teams. It has to be specified that an optimal self-organization takes time: it may be possible that for the first few sprints developers perform worse than when they work in the traditional way.

Some requirements are necessary to gain a good team self-organization:
*members are committed to clear, short-term goals;
*members can gauge the group’s progress;
*members can observe each other’s contribution;
*members feel safe to give each other unvarnished feedback.<ref name='James'>M. James,2010,Scrum Reference Card, Michael James,[[http://scrumreferencecard.com/]]</ref>

Conversely there are some conditions that can hander self-organization:
*geographical distribution: it is better if the whole team work in a room;
*boss/work dynamics: each member has to consider the others as peer to facilitate a fair communication between them;
*part-time team members;
*interruptions unrelated to Sprint goals.

===Scrum Master===
The scrum master worries that Scrum team can work without obstacles but he has no management authority over them. Essentially he has the aim to:
*create an environment to promote team self-organization;
*support team in the achievement of expected goals;
*ensure that events (e.g. daily Scrum meeting) take place in the right way;
*keep '''Scrum artefacts''' visible ('''Product Backlog''', '''Sprint Backlog''', '''Sprint burndown chart''' …).

==Sprint==
Sprint (or iteration) is the fundamental unit in which the work is divided; it is characterized by a fixed length of 2 weeks or 30 days and by a goal to achieve. At the beginning of each sprint Scrum team , Product Owner , Scrum Master and sometimes also stakeholders hold a meeting, called Sprint Planning meeting whose output is the Sprint Backlog where goals and requirements of the next Sprint are defined. Then other meetings inside development team will be held in order to define in more detail how achieving the common goals stated in the previous meeting.
==Scrum Meetings==
[[File:Scrum_meetings.png|350px|thumb|right|Scrum Meetings]]
Meeting are a fundamental tool used during the whole Scrum process. Usually they are facilitated by the Scrum master who has no decision-making authority over them . There are different typologies of meetings according to the different phase of the process in which we are.
===Sprint Planning Meeting===
At the beginning of each Sprint, the Product Owner and team hold a Sprint Planning Meeting to define on which '''Product Backlog Items (PBIs)''' they will go to work during the next Sprint. "The Product Owner is responsible for declaring which items are the most important to the business. The team is responsible for selecting the amount of work they feel they can implement" (''M. James, 2010)<ref name='James'></ref>.In this phase in perfect Lean perspective the team “pulls” work from the Product Backlog to the Sprint Backlog. At the end of the meeting the selected items are broken into a provisional list of Sprint task. The maximum time that can be used to do Planning meeting, known as '''timebox''', is of eight hours.

===Daily Scrum and Sprint Execution===
During the sprint every day members of the Scrum team hold a fifteen minutes meeting where they take stock of the situation. Usually they speak about what they did previous day, which impediments they faced and what they are going to do in the current day. To make these meetings shorter it is better that people are standing.
During sprint execution it is common to find out additional tasks necessary to achieve sprint goal; to keep the control over processes during sprint development it could be useful to maintain a current '''Sprint Task List''', a '''Sprint Burndown Chart''', and an '''Impediments List''': these are some artefacts that allow developer to understand where the project is located.

===Sprint Review Meeting===
At the end of every Sprint it is held a Review meeting where the scrum team has to explain to the Product Owner what they did during the previous sprint. Usually this meeting consists in a live demonstration of the working product increment after which Product Owner states which Items can be considered as done.
Items which are declared not done have to return to the Product Backlog to be ranked and reprioritized by the Product Owner with the help of the Scrum master. Last step of this meeting is to convert stakeholders’ feedback to a new Product Log, this task is consigned to both Product Owner and Scrum Master.
The Sprint Review Meeting is the appropriate meeting for external stakeholders (even end users) to attend.

===Sprint Retrospective Meeting===
During this meeting every member of the scrum team inspects his behaviour to identify some impediments that he faced during Sprint. There are mainly three kind of impediments in which developers can be involved:
*people who conduct performance evaluation are an obstacles to transparency of the team;
*human tendency of someone in the team to jump to conclusions and propose actions too quickly;
*geographical distribution of the team can be an impediments, team work better if they are delimited in a small place like a room.<ref name='James'></ref>

After identifying all these impediments Scrum master has the task to eliminate them.

===Backlog Refinement Meeting ===
Especially at the beginning of the project "most of the Product Backlog Items (PBIs) need refinement because they are too large and poorly understood" (''M. James, 2010'')<ref name='James'></ref>. In the Backlog Refinement Meeting, the team gave an estimation of the work left to complete Items in the Product Backlog and provides other technical information to help the Product Owner prioritize them.

==Artefacts==
[[File:Product_Backlog.png|200px|thumb|right|Product Backlog]]
===Product Backlog===

It is defined before the project beginning and then upgraded during the Backlog Refinement meeting ; it is made up by the whole group of items which have to be completed during the project in order to realize the final product. Every item is ranked and constantly reprioritized by the Product Owner. It is important that Product Backlog Is visible to the stakeholders.

===Product Backlog Item (PBI)===
An item specifies what has to be done but not how do it. Usually they are written in a User story to be understood also by stakeholders. Every items has a work load of 2-3 days and requires 2-3 people. It represents the basic unit of Product backlog.
[[File:Sprint_Backlog.png|200px|thumb|right|Sprint Backlog]]
===Sprint backlog===

It is defined at the beginning of each sprint during the Sprint Planning meeting where committed items and the main task that have to be done during the sprint are identified. It has to be visible to Scrum team and it can be upgraded during the sprint execution with additional task necessary to achieve the final goal.

===Sprint task===
Every item is divided into several tasks, each of them requires one day or less of work. A sprint task specifies how to achieve what is required by PBI. If the task takes more than one day of work, remaining effort is re-estimated daily, typically in hours.

===Sprint Burndown Chart===
[[File:Sprint_burndown_chart.png|300px|thumb|right|Sprint Burndown Chart]]
This tool is used to facilitate self-organization of the team. It indicates the total remaining team task hours within one Sprint. Usually chart shows a decreasing line but if there are some re-estimation it may be possible that line increase for then going down.

=Limitations=
Scrum method was often used in the object-oriented software development. Actually this technique are applied not only on software but also on other products from different sectors like wheelchairs, semiconductors and mortgages.
Scrum has to be used in those projects where people cannot rely on the plan-driven approaches like Waterfall, cause of unknown requirements and technology.
[[File:Graph.png|300px|thumb|right|Predictability of a Project]]
Conversely if the projects is placed under precise and stable conditions it is better to use one of the traditional model which allow to have a fixed planning over the whole project. In this case Scrum method would involve in a waste of resources and money because he is working on a field that is not its responsibility.

Michael James in his “Scrum Reference card” explains with a simple graphics in which conditions Scrum should be used and which ones are not. James defines the predictability of the projects on the base of two features: knowledge of the requirements and knowledge of the level of technology required. A project which provides known requirements and a known level of technology should be carried out with a plan-driven model. It these conditions are not met it is better to use an empirical approach like Scrum.<ref name='James'></ref>

=References=
<references/>

Scrum Methodology in Agile Software Development

2015-09-27T09:00:04Z

S150821: /* Application */

Today market is affected by uncertainly and sudden changes, in these conditions most of the models used in the 20th century to develop software are not still appropriate. Waterfall model , probably the most famous between them, is characterized by a stiff structure which can’t cope with the turbulent needs of actual market.
In recent years many innovations are been enhanced in software engineering with a particular focus on the flexibility of these methods in order to cope with the customer’s and market’s needs; surely '''Agile Software Development''' is between them.

ASD embraces the principles of lean production by applying them in software development to avoid waste and increase responsiveness to change. It represents the solution to the unpredictability of the market where the capacity to welcome change even late in development to satisfy customers is required.
This article deals with Agile Software Development with a particular focus on one of its most used technique : '''Scrum Methodology'''.

=Scrum Methodology=
Scrum is an iterative method used to develop software, it can be placed inside the group of methods which are used in '''Agile Software Development'''. This word is taken from rugby and represents that phase of the match where an ordered formation of players, with arms interlocked and heads down, push forward against a similar group to gain possession of the ball. This method provides that "work is divided into small chunks to manage complexity and to get early feedback from customers and end users" (''S. Augustine, 2005'')<ref>S. Augustine,2005,Prentice Hall PTR,Managing Agile Projects</ref>; software development is carried out by small working team that allow rapid adjustment during the process and a quick delivery of the final product.

==Agile Software Development==
Some practitioners believed that traditional iterative model was not so responsive to changes that market required. They thought that to be Agile a process needs to accept change rather than stress predictability and that methods used to develop software has to respond to change as quickly as it arose rather than prevent changes.<ref name='Cohen'>D.Cohen,M.Lindval,P. Costa,Fraunhofer Center Maryland, Agile Software Development</ref>

It was in these circumstances that practitioners as Mary Poppendieck and Bob Charet started to take inspiration from Lean manufacturing principles and apply them to software development.
These are the main points ,according to Poppendieck, which make Lean Production so successful and that can be applied to software development:

*elimination of waste that does not add value to the customer such as diagram and models that do not add value to the final deliverable;
*minimize inventory such as requirements and design documents;
*maximize flow by using iterative development to reduce development time;
*pull from demand;
*empower workers that means “tell developer what needs to be done not how to do it";
*meet customer requirements – work closely with the customer, allowing them to change their minds
*do it right the first time – test early and refactor when necessary;
*abolish local optimization – flexibly manage scope;
*partner with suppliers – avoid adversarial relationships, work towards developing the best software;
*create a culture of continuous improvement – allow the process to improve, learn from mistakes and successes.<ref name='Cohen'></ref><ref>M. Poppendieck, T. Poppendieck, 2003, Addison Wesley, Lean Software Development: An Agile Toolkit[[http://www.poppendieck.com/]]</ref>

===Manifesto for the Agile Software development===
A few years before Poppoendieck’s publication on February 2001 main principles of Agile Software development were stated by a group of 17 software developers which published “Manifesto for the Agile Software Development”.<ref>K. Beck et all., 2001, Manifesto for Agile Software Development[http://www.agilemanifesto.org/]</ref>

From reading these few words it is possible to identify what are the main innovations that ASD introduced in Software development:
[[File:Agilemanifesto.jpg|400px|thumb|right|Manifesto for the Agile Software development]]

*'''“Individuals and interactions”''' : with these words founders want to remark the power of human being creativity, and his ability to collaborate with other similar. The stiffness of Waterfall model is instead represented by “processes and tools” where people has to follow only what the plan requires.
*'''“Working software “''' : there is a clear reference to the new way to develop software where at every iteration a working program is realised, differently from the earlier model in which a working program couldn’t be seen until the end of the project. This feature is put over the “comprehensive documentation” which characterizes especially Waterfall model.
*'''“Customer collaboration”''' : means that there must be a straight relationship between customer and developer in order to define time by time the projects requirements and evaluate every realise.
*'''“Responding to change over following a plan”''' : this sentence encloses the essence of Agile software Development that is to cope with turbulent markets by being flexible and by responding quickly to change, instead of being bound by planning. This concept is remarked by the founders in one of the twelve principles which follow the manifesto which says “Welcome changing requirements, even late in development […]”.

=Application=
[[File:Scrum_Framework.png|350px|thumb|right|Scrum Framework]]
There are two concepts that are at the basement of Scrum methodology: '''iterative development''' and '''team working'''. Developing in iterations allow Scrum team to adapt quickly to changing requirements, while working in close location and focusing on communication allow team to make decisions and act on them immediately rather than wait on correspondence.<ref name='Cohen'></ref>

Basically Scrum consists in a sequence of fixed-length iterations called [[http://apppm.man.dtu.dk/index.php/Scrum_Methodology_in_Agile_Software_Development#Sprint= Sprint|Sprint]] managed by one or more '''cross-functional and self-organizing teams''' each composed by seven people that aim at a common goal and that usually work only on the software development. There are instead other two figures that manage all things that are in support of the development process: one is '''Product Owner''' who mainly handles customers contacts and the other is '''Scrum Master''' whose main task is to ensure that development team can work without obstacles.

Each sprint usually lasts from 2 to 4 weeks, in this period there are at least one meeting between the Product Owner and Development Team to define the main objectives; then there are short daily meetings held every morning to enhance communication and inform customers, developers, and managers on the status of the project, identify any problems encountered, and keep the entire team focused on a common goal.<ref name='Cohen'></ref>

==Main figures in Scrum==
===Product Owner===
Product owner is the link between customers and development team, he ensures that deliverables are in line with customers’ expectation and that stakeholders’ interests are fulfilled. He has also the task to fill out customer-centric items (typically '''user stories'''), ranks and prioritizes them before adds them to '''Product Backlog'''.

Usually development teams have only one Product owner, but differently from the Scrum master, he only takes care of the business side and does not interfere with the scrum team about the technological issues. At the beginning of each Sprint the Product Owner holds a Sprint Planning Meeting to state on which Product Backlog Items Scrum team will go to work during the next Sprint. In this phase he defines what are the most important items for that business, in according to customer’s needs.

===Development Team===
Development team task is to provide Product Backlog Items (PBIs) at the end of every Sprint in according with customers’ requirements after negotiating commitments with the Product Owner.
Usually each team is composed by '''cross-functional members''' that allow an all-round software development; the main figures that there must be are a mix of software engineers, architects, programmers, analysts, QA experts, testers, and UI designers.

The size of the team is an important point, the group members' number influences capacity of people to communicate and work together: it is recommended that a scrum team is composed not more than nine people, usually seven.

Another important characteristic is the Self-organization of the group which facilitates members’ creativity and increases team cohesiveness: for this reason it is better to not change members of a team after they have worked together, especially if they had success in their project. After working together team members gain a mutual understanding that increases their capacity of team working, this synergy cannot be acquired if team are continuously changed.

A further point that characterized the good outcomes of a scrum team is location: people are most successful when located in the same room, particularly for the first few Sprints: this facilitates communication and information sharing.

====Team self-organization====
Team self-organization is a crucial point in the scrum methodology : with this concept it means that “it is told developer what needs to be done not how to do it”, they can autonomously choose the way to reach commitments.
As it is said previously during Sprint execution, team members develop an intrinsic interest in shared goals and learn to manage each other to achieve them, for this reason self-organizing teams can radically outperform larger than traditionally managed teams. It has to be specified that an optimal self-organization takes time: it may be possible that for the first few sprints developers perform worse than when they work in the traditional way.

Some requirements are necessary to gain a good team self-organization:
*members are committed to clear, short-term goals;
*members can gauge the group’s progress;
*members can observe each other’s contribution;
*members feel safe to give each other unvarnished feedback.<ref name='James'>M. James,2010,Scrum Reference Card, Michael James,[[http://scrumreferencecard.com/]]</ref>

Conversely there are some conditions that can hander self-organization:
*geographical distribution: it is better if the whole team work in a room;
*boss/work dynamics: each member has to consider the others as peer to facilitate a fair communication between them;
*part-time team members;
*interruptions unrelated to Sprint goals.

===Scrum Master===
The scrum master worries that Scrum team can work without obstacles but he has no management authority over them. Essentially he has the aim to:
*create an environment to promote team self-organization;
*support team in the achievement of expected goals;
*ensure that events (e.g. daily Scrum meeting) take place in the right way;
*keep '''Scrum artefacts''' visible ('''Product Backlog''', '''Sprint Backlog''', '''Sprint burndown chart''' …).

==Sprint==
Sprint (or iteration) is the fundamental unit in which the work is divided; it is characterized by a fixed length of 2 weeks or 30 days and by a goal to achieve. At the beginning of each sprint Scrum team , Product Owner , Scrum Master and sometimes also stakeholders hold a meeting, called Sprint Planning meeting whose output is the Sprint Backlog where goals and requirements of the next Sprint are defined. Then other meetings inside development team will be held in order to define in more detail how achieving the common goals stated in the previous meeting.
==Scrum Meetings==
[[File:Scrum_meetings.png|350px|thumb|right|Scrum Meetings]]
Meeting are a fundamental tool used during the whole Scrum process. Usually they are facilitated by the Scrum master who has no decision-making authority over them . There are different typologies of meetings according to the different phase of the process in which we are.
===Sprint Planning Meeting===
At the beginning of each Sprint, the Product Owner and team hold a Sprint Planning Meeting to define on which '''Product Backlog Items (PBIs)''' they will go to work during the next Sprint. "The Product Owner is responsible for declaring which items are the most important to the business. The team is responsible for selecting the amount of work they feel they can implement" (''M. James, 2010)<ref name='James'></ref>.In this phase in perfect Lean perspective the team “pulls” work from the Product Backlog to the Sprint Backlog. At the end of the meeting the selected items are broken into a provisional list of Sprint task. The maximum time that can be used to do Planning meeting, known as '''timebox''', is of eight hours.

===Daily Scrum and Sprint Execution===
During the sprint every day members of the Scrum team hold a fifteen minutes meeting where they take stock of the situation. Usually they speak about what they did previous day, which impediments they faced and what they are going to do in the current day. To make these meetings shorter it is better that people are standing.
During sprint execution it is common to find out additional tasks necessary to achieve sprint goal; to keep the control over processes during sprint development it could be useful to maintain a current '''Sprint Task List''', a '''Sprint Burndown Chart''', and an '''Impediments List''': these are some artefacts that allow developer to understand where the project is located.

===Sprint Review Meeting===
At the end of every Sprint it is held a Review meeting where the scrum team has to explain to the Product Owner what they did during the previous sprint. Usually this meeting consists in a live demonstration of the working product increment after which Product Owner states which Items can be considered as done.
Items which are declared not done have to return to the Product Backlog to be ranked and reprioritized by the Product Owner with the help of the Scrum master. Last step of this meeting is to convert stakeholders’ feedback to a new Product Log, this task is consigned to both Product Owner and Scrum Master.
The Sprint Review Meeting is the appropriate meeting for external stakeholders (even end users) to attend.

===Sprint Retrospective Meeting===
During this meeting every member of the scrum team inspects his behaviour to identify some impediments that he faced during Sprint. There are mainly three kind of impediments in which developers can be involved:
*people who conduct performance evaluation are an obstacles to transparency of the team;
*human tendency of someone in the team to jump to conclusions and propose actions too quickly;
*geographical distribution of the team can be an impediments, team work better if they are delimited in a small place like a room.<ref name='James'></ref>

After identifying all these impediments Scrum master has the task to eliminate them.

===Backlog Refinement Meeting ===
Especially at the beginning of the project "most of the Product Backlog Items (PBIs) need refinement because they are too large and poorly understood" (''M. James, 2010'')<ref name='James'></ref>. In the Backlog Refinement Meeting, the team gave an estimation of the work left to complete Items in the Product Backlog and provides other technical information to help the Product Owner prioritize them.

==Artefacts==
[[File:Product_Backlog.png|200px|thumb|right|Product Backlog]]
===Product Backlog===

It is defined before the project beginning and then upgraded during the Backlog Refinement meeting ; it is made up by the whole group of items which have to be completed during the project in order to realize the final product. Every item is ranked and constantly reprioritized by the Product Owner. It is important that Product Backlog Is visible to the stakeholders.

===Product Backlog Item (PBI)===
An item specifies what has to be done but not how do it. Usually they are written in a User story to be understood also by stakeholders. Every items has a work load of 2-3 days and requires 2-3 people. It represents the basic unit of Product backlog.
[[File:Sprint_Backlog.png|200px|thumb|right|Sprint Backlog]]
===Sprint backlog===

It is defined at the beginning of each sprint during the Sprint Planning meeting where committed items and the main task that have to be done during the sprint are identified. It has to be visible to Scrum team and it can be upgraded during the sprint execution with additional task necessary to achieve the final goal.

===Sprint task===
Every item is divided into several tasks, each of them requires one day or less of work. A sprint task specifies how to achieve what is required by PBI. If the task takes more than one day of work, remaining effort is re-estimated daily, typically in hours.

===Sprint Burndown Chart===
[[File:Sprint_burndown_chart.png|300px|thumb|right|Sprint Burndown Chart]]
This tool is used to facilitate self-organization of the team. It indicates the total remaining team task hours within one Sprint. Usually chart shows a decreasing line but if there are some re-estimation it may be possible that line increase for then going down.

=Limitations=
Scrum method was often used in the object-oriented software development. Actually this technique are applied not only on software but also on other products from different sectors like wheelchairs, semiconductors and mortgages.
Scrum has to be used in those projects where people cannot rely on the plan-driven approaches like Waterfall, cause of unknown requirements and technology.
[[File:Graph.png|300px|thumb|right|Predictability of a Project]]
Conversely if the projects is placed under precise and stable conditions it is better to use one of the traditional model which allow to have a fixed planning over the whole project. In this case Scrum method would involve in a waste of resources and money because he is working on a field that is not its responsibility.

Michael James in his “Scrum Reference card” explains with a simple graphics in which conditions Scrum should be used and which ones are not. James defines the predictability of the projects on the base of two features: knowledge of the requirements and knowledge of the level of technology required. A project which provides known requirements and a known level of technology should be carried out with a plan-driven model. It these conditions are not met it is better to use an empirical approach like Scrum.<ref name='James'></ref>

=References=
<references/>

Scrum Methodology in Agile Software Development

2015-09-27T08:57:13Z

S150821: /* Application */

Today market is affected by uncertainly and sudden changes, in these conditions most of the models used in the 20th century to develop software are not still appropriate. Waterfall model , probably the most famous between them, is characterized by a stiff structure which can’t cope with the turbulent needs of actual market.
In recent years many innovations are been enhanced in software engineering with a particular focus on the flexibility of these methods in order to cope with the customer’s and market’s needs; surely '''Agile Software Development''' is between them.

ASD embraces the principles of lean production by applying them in software development to avoid waste and increase responsiveness to change. It represents the solution to the unpredictability of the market where the capacity to welcome change even late in development to satisfy customers is required.
This article deals with Agile Software Development with a particular focus on one of its most used technique : '''Scrum Methodology'''.

=Scrum Methodology=
Scrum is an iterative method used to develop software, it can be placed inside the group of methods which are used in '''Agile Software Development'''. This word is taken from rugby and represents that phase of the match where an ordered formation of players, with arms interlocked and heads down, push forward against a similar group to gain possession of the ball. This method provides that "work is divided into small chunks to manage complexity and to get early feedback from customers and end users" (''S. Augustine, 2005'')<ref>S. Augustine,2005,Prentice Hall PTR,Managing Agile Projects</ref>; software development is carried out by small working team that allow rapid adjustment during the process and a quick delivery of the final product.

==Agile Software Development==
Some practitioners believed that traditional iterative model was not so responsive to changes that market required. They thought that to be Agile a process needs to accept change rather than stress predictability and that methods used to develop software has to respond to change as quickly as it arose rather than prevent changes.<ref name='Cohen'>D.Cohen,M.Lindval,P. Costa,Fraunhofer Center Maryland, Agile Software Development</ref>

It was in these circumstances that practitioners as Mary Poppendieck and Bob Charet started to take inspiration from Lean manufacturing principles and apply them to software development.
These are the main points ,according to Poppendieck, which make Lean Production so successful and that can be applied to software development:

*elimination of waste that does not add value to the customer such as diagram and models that do not add value to the final deliverable;
*minimize inventory such as requirements and design documents;
*maximize flow by using iterative development to reduce development time;
*pull from demand;
*empower workers that means “tell developer what needs to be done not how to do it";
*meet customer requirements – work closely with the customer, allowing them to change their minds
*do it right the first time – test early and refactor when necessary;
*abolish local optimization – flexibly manage scope;
*partner with suppliers – avoid adversarial relationships, work towards developing the best software;
*create a culture of continuous improvement – allow the process to improve, learn from mistakes and successes.<ref name='Cohen'></ref><ref>M. Poppendieck, T. Poppendieck, 2003, Addison Wesley, Lean Software Development: An Agile Toolkit[[http://www.poppendieck.com/]]</ref>

===Manifesto for the Agile Software development===
A few years before Poppoendieck’s publication on February 2001 main principles of Agile Software development were stated by a group of 17 software developers which published “Manifesto for the Agile Software Development”.<ref>K. Beck et all., 2001, Manifesto for Agile Software Development[http://www.agilemanifesto.org/]</ref>

From reading these few words it is possible to identify what are the main innovations that ASD introduced in Software development:
[[File:Agilemanifesto.jpg|400px|thumb|right|Manifesto for the Agile Software development]]

*'''“Individuals and interactions”''' : with these words founders want to remark the power of human being creativity, and his ability to collaborate with other similar. The stiffness of Waterfall model is instead represented by “processes and tools” where people has to follow only what the plan requires.
*'''“Working software “''' : there is a clear reference to the new way to develop software where at every iteration a working program is realised, differently from the earlier model in which a working program couldn’t be seen until the end of the project. This feature is put over the “comprehensive documentation” which characterizes especially Waterfall model.
*'''“Customer collaboration”''' : means that there must be a straight relationship between customer and developer in order to define time by time the projects requirements and evaluate every realise.
*'''“Responding to change over following a plan”''' : this sentence encloses the essence of Agile software Development that is to cope with turbulent markets by being flexible and by responding quickly to change, instead of being bound by planning. This concept is remarked by the founders in one of the twelve principles which follow the manifesto which says “Welcome changing requirements, even late in development […]”.

=Application=
[[File:Scrum_Framework.png|350px|thumb|right|Scrum Framework]]
There are two concepts that are at the basement of Scrum methodology: '''iterative development''' and '''team working'''. Developing in iterations allow Scrum team to adapt quickly to changing requirements, while working in close location and focusing on communication allow team to make decisions and act on them immediately rather than wait on correspondence.<ref name='Cohen'></ref>

Basically Scrum consists in a sequence of fixed-length iterations called [[wikipedia:Sprint|Sprint]] managed by one or more '''cross-functional and self-organizing teams''' each composed by seven people that aim at a common goal and that usually work only on the software development. There are instead other two figures that manage all things that are in support of the development process: one is '''Product Owner''' who mainly handles customers contacts and the other is '''Scrum Master''' whose main task is to ensure that development team can work without obstacles.

Each sprint usually lasts from 2 to 4 weeks, in this period there are at least one meeting between the Product Owner and Development Team to define the main objectives; then there are short daily meetings held every morning to enhance communication and inform customers, developers, and managers on the status of the project, identify any problems encountered, and keep the entire team focused on a common goal.<ref name='Cohen'></ref>

==Main figures in Scrum==
===Product Owner===
Product owner is the link between customers and development team, he ensures that deliverables are in line with customers’ expectation and that stakeholders’ interests are fulfilled. He has also the task to fill out customer-centric items (typically '''user stories'''), ranks and prioritizes them before adds them to '''Product Backlog'''.

Usually development teams have only one Product owner, but differently from the Scrum master, he only takes care of the business side and does not interfere with the scrum team about the technological issues. At the beginning of each Sprint the Product Owner holds a Sprint Planning Meeting to state on which Product Backlog Items Scrum team will go to work during the next Sprint. In this phase he defines what are the most important items for that business, in according to customer’s needs.

===Development Team===
Development team task is to provide Product Backlog Items (PBIs) at the end of every Sprint in according with customers’ requirements after negotiating commitments with the Product Owner.
Usually each team is composed by '''cross-functional members''' that allow an all-round software development; the main figures that there must be are a mix of software engineers, architects, programmers, analysts, QA experts, testers, and UI designers.

The size of the team is an important point, the group members' number influences capacity of people to communicate and work together: it is recommended that a scrum team is composed not more than nine people, usually seven.

Another important characteristic is the Self-organization of the group which facilitates members’ creativity and increases team cohesiveness: for this reason it is better to not change members of a team after they have worked together, especially if they had success in their project. After working together team members gain a mutual understanding that increases their capacity of team working, this synergy cannot be acquired if team are continuously changed.

A further point that characterized the good outcomes of a scrum team is location: people are most successful when located in the same room, particularly for the first few Sprints: this facilitates communication and information sharing.

====Team self-organization====
Team self-organization is a crucial point in the scrum methodology : with this concept it means that “it is told developer what needs to be done not how to do it”, they can autonomously choose the way to reach commitments.
As it is said previously during Sprint execution, team members develop an intrinsic interest in shared goals and learn to manage each other to achieve them, for this reason self-organizing teams can radically outperform larger than traditionally managed teams. It has to be specified that an optimal self-organization takes time: it may be possible that for the first few sprints developers perform worse than when they work in the traditional way.

Some requirements are necessary to gain a good team self-organization:
*members are committed to clear, short-term goals;
*members can gauge the group’s progress;
*members can observe each other’s contribution;
*members feel safe to give each other unvarnished feedback.<ref name='James'>M. James,2010,Scrum Reference Card, Michael James,[[http://scrumreferencecard.com/]]</ref>

Conversely there are some conditions that can hander self-organization:
*geographical distribution: it is better if the whole team work in a room;
*boss/work dynamics: each member has to consider the others as peer to facilitate a fair communication between them;
*part-time team members;
*interruptions unrelated to Sprint goals.

===Scrum Master===
The scrum master worries that Scrum team can work without obstacles but he has no management authority over them. Essentially he has the aim to:
*create an environment to promote team self-organization;
*support team in the achievement of expected goals;
*ensure that events (e.g. daily Scrum meeting) take place in the right way;
*keep '''Scrum artefacts''' visible ('''Product Backlog''', '''Sprint Backlog''', '''Sprint burndown chart''' …).

==Sprint==
Sprint (or iteration) is the fundamental unit in which the work is divided; it is characterized by a fixed length of 2 weeks or 30 days and by a goal to achieve. At the beginning of each sprint Scrum team , Product Owner , Scrum Master and sometimes also stakeholders hold a meeting, called Sprint Planning meeting whose output is the Sprint Backlog where goals and requirements of the next Sprint are defined. Then other meetings inside development team will be held in order to define in more detail how achieving the common goals stated in the previous meeting.
==Scrum Meetings==
[[File:Scrum_meetings.png|350px|thumb|right|Scrum Meetings]]
Meeting are a fundamental tool used during the whole Scrum process. Usually they are facilitated by the Scrum master who has no decision-making authority over them . There are different typologies of meetings according to the different phase of the process in which we are.
===Sprint Planning Meeting===
At the beginning of each Sprint, the Product Owner and team hold a Sprint Planning Meeting to define on which '''Product Backlog Items (PBIs)''' they will go to work during the next Sprint. "The Product Owner is responsible for declaring which items are the most important to the business. The team is responsible for selecting the amount of work they feel they can implement" (''M. James, 2010)<ref name='James'></ref>.In this phase in perfect Lean perspective the team “pulls” work from the Product Backlog to the Sprint Backlog. At the end of the meeting the selected items are broken into a provisional list of Sprint task. The maximum time that can be used to do Planning meeting, known as '''timebox''', is of eight hours.

===Daily Scrum and Sprint Execution===
During the sprint every day members of the Scrum team hold a fifteen minutes meeting where they take stock of the situation. Usually they speak about what they did previous day, which impediments they faced and what they are going to do in the current day. To make these meetings shorter it is better that people are standing.
During sprint execution it is common to find out additional tasks necessary to achieve sprint goal; to keep the control over processes during sprint development it could be useful to maintain a current '''Sprint Task List''', a '''Sprint Burndown Chart''', and an '''Impediments List''': these are some artefacts that allow developer to understand where the project is located.

===Sprint Review Meeting===
At the end of every Sprint it is held a Review meeting where the scrum team has to explain to the Product Owner what they did during the previous sprint. Usually this meeting consists in a live demonstration of the working product increment after which Product Owner states which Items can be considered as done.
Items which are declared not done have to return to the Product Backlog to be ranked and reprioritized by the Product Owner with the help of the Scrum master. Last step of this meeting is to convert stakeholders’ feedback to a new Product Log, this task is consigned to both Product Owner and Scrum Master.
The Sprint Review Meeting is the appropriate meeting for external stakeholders (even end users) to attend.

===Sprint Retrospective Meeting===
During this meeting every member of the scrum team inspects his behaviour to identify some impediments that he faced during Sprint. There are mainly three kind of impediments in which developers can be involved:
*people who conduct performance evaluation are an obstacles to transparency of the team;
*human tendency of someone in the team to jump to conclusions and propose actions too quickly;
*geographical distribution of the team can be an impediments, team work better if they are delimited in a small place like a room.<ref name='James'></ref>

After identifying all these impediments Scrum master has the task to eliminate them.

===Backlog Refinement Meeting ===
Especially at the beginning of the project "most of the Product Backlog Items (PBIs) need refinement because they are too large and poorly understood" (''M. James, 2010'')<ref name='James'></ref>. In the Backlog Refinement Meeting, the team gave an estimation of the work left to complete Items in the Product Backlog and provides other technical information to help the Product Owner prioritize them.

==Artefacts==
[[File:Product_Backlog.png|200px|thumb|right|Product Backlog]]
===Product Backlog===

It is defined before the project beginning and then upgraded during the Backlog Refinement meeting ; it is made up by the whole group of items which have to be completed during the project in order to realize the final product. Every item is ranked and constantly reprioritized by the Product Owner. It is important that Product Backlog Is visible to the stakeholders.

===Product Backlog Item (PBI)===
An item specifies what has to be done but not how do it. Usually they are written in a User story to be understood also by stakeholders. Every items has a work load of 2-3 days and requires 2-3 people. It represents the basic unit of Product backlog.
[[File:Sprint_Backlog.png|200px|thumb|right|Sprint Backlog]]
===Sprint backlog===

It is defined at the beginning of each sprint during the Sprint Planning meeting where committed items and the main task that have to be done during the sprint are identified. It has to be visible to Scrum team and it can be upgraded during the sprint execution with additional task necessary to achieve the final goal.

===Sprint task===
Every item is divided into several tasks, each of them requires one day or less of work. A sprint task specifies how to achieve what is required by PBI. If the task takes more than one day of work, remaining effort is re-estimated daily, typically in hours.

===Sprint Burndown Chart===
[[File:Sprint_burndown_chart.png|300px|thumb|right|Sprint Burndown Chart]]
This tool is used to facilitate self-organization of the team. It indicates the total remaining team task hours within one Sprint. Usually chart shows a decreasing line but if there are some re-estimation it may be possible that line increase for then going down.

=Limitations=
Scrum method was often used in the object-oriented software development. Actually this technique are applied not only on software but also on other products from different sectors like wheelchairs, semiconductors and mortgages.
Scrum has to be used in those projects where people cannot rely on the plan-driven approaches like Waterfall, cause of unknown requirements and technology.
[[File:Graph.png|300px|thumb|right|Predictability of a Project]]
Conversely if the projects is placed under precise and stable conditions it is better to use one of the traditional model which allow to have a fixed planning over the whole project. In this case Scrum method would involve in a waste of resources and money because he is working on a field that is not its responsibility.

Michael James in his “Scrum Reference card” explains with a simple graphics in which conditions Scrum should be used and which ones are not. James defines the predictability of the projects on the base of two features: knowledge of the requirements and knowledge of the level of technology required. A project which provides known requirements and a known level of technology should be carried out with a plan-driven model. It these conditions are not met it is better to use an empirical approach like Scrum.<ref name='James'></ref>

=References=
<references/>

Scrum Methodology in Agile Software Development

2015-09-27T08:32:09Z

S150821: /* Manifesto for the Agile Software development */

Today market is affected by uncertainly and sudden changes, in these conditions most of the models used in the 20th century to develop software are not still appropriate. Waterfall model , probably the most famous between them, is characterized by a stiff structure which can’t cope with the turbulent needs of actual market.
In recent years many innovations are been enhanced in software engineering with a particular focus on the flexibility of these methods in order to cope with the customer’s and market’s needs; surely '''Agile Software Development''' is between them.

ASD embraces the principles of lean production by applying them in software development to avoid waste and increase responsiveness to change. It represents the solution to the unpredictability of the market where the capacity to welcome change even late in development to satisfy customers is required.
This article deals with Agile Software Development with a particular focus on one of its most used technique : '''Scrum Methodology'''.

=Scrum Methodology=
Scrum is an iterative method used to develop software, it can be placed inside the group of methods which are used in '''Agile Software Development'''. This word is taken from rugby and represents that phase of the match where an ordered formation of players, with arms interlocked and heads down, push forward against a similar group to gain possession of the ball. This method provides that "work is divided into small chunks to manage complexity and to get early feedback from customers and end users" (''S. Augustine, 2005'')<ref>S. Augustine,2005,Prentice Hall PTR,Managing Agile Projects</ref>; software development is carried out by small working team that allow rapid adjustment during the process and a quick delivery of the final product.

==Agile Software Development==
Some practitioners believed that traditional iterative model was not so responsive to changes that market required. They thought that to be Agile a process needs to accept change rather than stress predictability and that methods used to develop software has to respond to change as quickly as it arose rather than prevent changes.<ref name='Cohen'>D.Cohen,M.Lindval,P. Costa,Fraunhofer Center Maryland, Agile Software Development</ref>

It was in these circumstances that practitioners as Mary Poppendieck and Bob Charet started to take inspiration from Lean manufacturing principles and apply them to software development.
These are the main points ,according to Poppendieck, which make Lean Production so successful and that can be applied to software development:

*elimination of waste that does not add value to the customer such as diagram and models that do not add value to the final deliverable;
*minimize inventory such as requirements and design documents;
*maximize flow by using iterative development to reduce development time;
*pull from demand;
*empower workers that means “tell developer what needs to be done not how to do it";
*meet customer requirements – work closely with the customer, allowing them to change their minds
*do it right the first time – test early and refactor when necessary;
*abolish local optimization – flexibly manage scope;
*partner with suppliers – avoid adversarial relationships, work towards developing the best software;
*create a culture of continuous improvement – allow the process to improve, learn from mistakes and successes.<ref name='Cohen'></ref><ref>M. Poppendieck, T. Poppendieck, 2003, Addison Wesley, Lean Software Development: An Agile Toolkit[[http://www.poppendieck.com/]]</ref>

===Manifesto for the Agile Software development===
A few years before Poppoendieck’s publication on February 2001 main principles of Agile Software development were stated by a group of 17 software developers which published “Manifesto for the Agile Software Development”.<ref>K. Beck et all., 2001, Manifesto for Agile Software Development[http://www.agilemanifesto.org/]</ref>

From reading these few words it is possible to identify what are the main innovations that ASD introduced in Software development:
[[File:Agilemanifesto.jpg|400px|thumb|right|Manifesto for the Agile Software development]]

*'''“Individuals and interactions”''' : with these words founders want to remark the power of human being creativity, and his ability to collaborate with other similar. The stiffness of Waterfall model is instead represented by “processes and tools” where people has to follow only what the plan requires.
*'''“Working software “''' : there is a clear reference to the new way to develop software where at every iteration a working program is realised, differently from the earlier model in which a working program couldn’t be seen until the end of the project. This feature is put over the “comprehensive documentation” which characterizes especially Waterfall model.
*'''“Customer collaboration”''' : means that there must be a straight relationship between customer and developer in order to define time by time the projects requirements and evaluate every realise.
*'''“Responding to change over following a plan”''' : this sentence encloses the essence of Agile software Development that is to cope with turbulent markets by being flexible and by responding quickly to change, instead of being bound by planning. This concept is remarked by the founders in one of the twelve principles which follow the manifesto which says “Welcome changing requirements, even late in development […]”.

=Application=
[[File:Scrum_Framework.png|350px|thumb|right|Scrum Framework]]
There are two concepts that are at the basement of Scrum methodology: '''iterative development''' and '''team working'''. Developing in iterations allow Scrum team to adapt quickly to changing requirements, while working in close location and focusing on communication allow team to make decisions and act on them immediately rather than wait on correspondence.<ref name='Cohen'></ref>

Basically Scrum consists in a sequence of fixed-length iterations called '''Sprints''' managed by one or more '''cross-functional and self-organizing teams''' each composed by seven people that aim at a common goal and that usually work only on the software development. There are instead other two figures that manage all things that are in support of the development process: one is '''Product Owner''' who mainly handles customers contacts and the other is '''Scrum Master''' whose main task is to ensure that development team can work without obstacles.

Each sprint usually lasts from 2 to 4 weeks, in this period there are at least one meeting between the Product Owner and Development Team to define the main objectives; then there are short daily meetings held every morning to enhance communication and inform customers, developers, and managers on the status of the project, identify any problems encountered, and keep the entire team focused on a common goal.<ref name='Cohen'></ref>

==Main figures in Scrum==
===Product Owner===
Product owner is the link between customers and development team, he ensures that deliverables are in line with customers’ expectation and that stakeholders’ interests are fulfilled. He has also the task to fill out customer-centric items (typically '''user stories'''), ranks and prioritizes them before adds them to '''Product Backlog'''.

Usually development teams have only one Product owner, but differently from the Scrum master, he only takes care of the business side and does not interfere with the scrum team about the technological issues. At the beginning of each Sprint the Product Owner holds a Sprint Planning Meeting to state on which Product Backlog Items Scrum team will go to work during the next Sprint. In this phase he defines what are the most important items for that business, in according to customer’s needs.

===Development Team===
Development team task is to provide Product Backlog Items (PBIs) at the end of every Sprint in according with customers’ requirements after negotiating commitments with the Product Owner.
Usually each team is composed by '''cross-functional members''' that allow an all-round software development; the main figures that there must be are a mix of software engineers, architects, programmers, analysts, QA experts, testers, and UI designers.

The size of the team is an important point, the group members' number influences capacity of people to communicate and work together: it is recommended that a scrum team is composed not more than nine people, usually seven.

Another important characteristic is the Self-organization of the group which facilitates members’ creativity and increases team cohesiveness: for this reason it is better to not change members of a team after they have worked together, especially if they had success in their project. After working together team members gain a mutual understanding that increases their capacity of team working, this synergy cannot be acquired if team are continuously changed.

A further point that characterized the good outcomes of a scrum team is location: people are most successful when located in the same room, particularly for the first few Sprints: this facilitates communication and information sharing.

====Team self-organization====
Team self-organization is a crucial point in the scrum methodology : with this concept it means that “it is told developer what needs to be done not how to do it”, they can autonomously choose the way to reach commitments.
As it is said previously during Sprint execution, team members develop an intrinsic interest in shared goals and learn to manage each other to achieve them, for this reason self-organizing teams can radically outperform larger than traditionally managed teams. It has to be specified that an optimal self-organization takes time: it may be possible that for the first few sprints developers perform worse than when they work in the traditional way.

Some requirements are necessary to gain a good team self-organization:
*members are committed to clear, short-term goals;
*members can gauge the group’s progress;
*members can observe each other’s contribution;
*members feel safe to give each other unvarnished feedback.<ref name='James'>M. James,2010,Scrum Reference Card, Michael James,[[http://scrumreferencecard.com/]]</ref>

Conversely there are some conditions that can hander self-organization:
*geographical distribution: it is better if the whole team work in a room;
*boss/work dynamics: each member has to consider the others as peer to facilitate a fair communication between them;
*part-time team members;
*interruptions unrelated to Sprint goals.

===Scrum Master===
The scrum master worries that Scrum team can work without obstacles but he has no management authority over them. Essentially he has the aim to:
*create an environment to promote team self-organization;
*support team in the achievement of expected goals;
*ensure that events (e.g. daily Scrum meeting) take place in the right way;
*keep '''Scrum artefacts''' visible ('''Product Backlog''', '''Sprint Backlog''', '''Sprint burndown chart''' …).

==Sprint==
Sprint (or iteration) is the fundamental unit in which the work is divided; it is characterized by a fixed length of 2 weeks or 30 days and by a goal to achieve. At the beginning of each sprint Scrum team , Product Owner , Scrum Master and sometimes also stakeholders hold a meeting, called Sprint Planning meeting whose output is the Sprint Backlog where goals and requirements of the next Sprint are defined. Then other meetings inside development team will be held in order to define in more detail how achieving the common goals stated in the previous meeting.
==Scrum Meetings==
[[File:Scrum_meetings.png|350px|thumb|right|Scrum Meetings]]
Meeting are a fundamental tool used during the whole Scrum process. Usually they are facilitated by the Scrum master who has no decision-making authority over them . There are different typologies of meetings according to the different phase of the process in which we are.
===Sprint Planning Meeting===
At the beginning of each Sprint, the Product Owner and team hold a Sprint Planning Meeting to define on which '''Product Backlog Items (PBIs)''' they will go to work during the next Sprint. "The Product Owner is responsible for declaring which items are the most important to the business. The team is responsible for selecting the amount of work they feel they can implement" (''M. James, 2010)<ref name='James'></ref>.In this phase in perfect Lean perspective the team “pulls” work from the Product Backlog to the Sprint Backlog. At the end of the meeting the selected items are broken into a provisional list of Sprint task. The maximum time that can be used to do Planning meeting, known as '''timebox''', is of eight hours.

===Daily Scrum and Sprint Execution===
During the sprint every day members of the Scrum team hold a fifteen minutes meeting where they take stock of the situation. Usually they speak about what they did previous day, which impediments they faced and what they are going to do in the current day. To make these meetings shorter it is better that people are standing.
During sprint execution it is common to find out additional tasks necessary to achieve sprint goal; to keep the control over processes during sprint development it could be useful to maintain a current '''Sprint Task List''', a '''Sprint Burndown Chart''', and an '''Impediments List''': these are some artefacts that allow developer to understand where the project is located.

===Sprint Review Meeting===
At the end of every Sprint it is held a Review meeting where the scrum team has to explain to the Product Owner what they did during the previous sprint. Usually this meeting consists in a live demonstration of the working product increment after which Product Owner states which Items can be considered as done.
Items which are declared not done have to return to the Product Backlog to be ranked and reprioritized by the Product Owner with the help of the Scrum master. Last step of this meeting is to convert stakeholders’ feedback to a new Product Log, this task is consigned to both Product Owner and Scrum Master.
The Sprint Review Meeting is the appropriate meeting for external stakeholders (even end users) to attend.

===Sprint Retrospective Meeting===
During this meeting every member of the scrum team inspects his behaviour to identify some impediments that he faced during Sprint. There are mainly three kind of impediments in which developers can be involved:
*people who conduct performance evaluation are an obstacles to transparency of the team;
*human tendency of someone in the team to jump to conclusions and propose actions too quickly;
*geographical distribution of the team can be an impediments, team work better if they are delimited in a small place like a room.<ref name='James'></ref>

After identifying all these impediments Scrum master has the task to eliminate them.

===Backlog Refinement Meeting ===
Especially at the beginning of the project "most of the Product Backlog Items (PBIs) need refinement because they are too large and poorly understood" (''M. James, 2010'')<ref name='James'></ref>. In the Backlog Refinement Meeting, the team gave an estimation of the work left to complete Items in the Product Backlog and provides other technical information to help the Product Owner prioritize them.

==Artefacts==
[[File:Product_Backlog.png|200px|thumb|right|Product Backlog]]
===Product Backlog===

It is defined before the project beginning and then upgraded during the Backlog Refinement meeting ; it is made up by the whole group of items which have to be completed during the project in order to realize the final product. Every item is ranked and constantly reprioritized by the Product Owner. It is important that Product Backlog Is visible to the stakeholders.

===Product Backlog Item (PBI)===
An item specifies what has to be done but not how do it. Usually they are written in a User story to be understood also by stakeholders. Every items has a work load of 2-3 days and requires 2-3 people. It represents the basic unit of Product backlog.
[[File:Sprint_Backlog.png|200px|thumb|right|Sprint Backlog]]
===Sprint backlog===

It is defined at the beginning of each sprint during the Sprint Planning meeting where committed items and the main task that have to be done during the sprint are identified. It has to be visible to Scrum team and it can be upgraded during the sprint execution with additional task necessary to achieve the final goal.

===Sprint task===
Every item is divided into several tasks, each of them requires one day or less of work. A sprint task specifies how to achieve what is required by PBI. If the task takes more than one day of work, remaining effort is re-estimated daily, typically in hours.

===Sprint Burndown Chart===
[[File:Sprint_burndown_chart.png|300px|thumb|right|Sprint Burndown Chart]]
This tool is used to facilitate self-organization of the team. It indicates the total remaining team task hours within one Sprint. Usually chart shows a decreasing line but if there are some re-estimation it may be possible that line increase for then going down.

=Limitations=
Scrum method was often used in the object-oriented software development. Actually this technique are applied not only on software but also on other products from different sectors like wheelchairs, semiconductors and mortgages.
Scrum has to be used in those projects where people cannot rely on the plan-driven approaches like Waterfall, cause of unknown requirements and technology.
[[File:Graph.png|300px|thumb|right|Predictability of a Project]]
Conversely if the projects is placed under precise and stable conditions it is better to use one of the traditional model which allow to have a fixed planning over the whole project. In this case Scrum method would involve in a waste of resources and money because he is working on a field that is not its responsibility.

Michael James in his “Scrum Reference card” explains with a simple graphics in which conditions Scrum should be used and which ones are not. James defines the predictability of the projects on the base of two features: knowledge of the requirements and knowledge of the level of technology required. A project which provides known requirements and a known level of technology should be carried out with a plan-driven model. It these conditions are not met it is better to use an empirical approach like Scrum.<ref name='James'></ref>

=References=
<references/>