Scrum method - Revision history

Tkokotas at 14:13, 18 December 2018

2018-12-18T14:13:02Z

← Older revision		Revision as of 14:13, 18 December 2018
Line 1:		Line 1:
			''Developed by Jakob Rolfsson''


	In the early days of software development, the usual waterfall method used for product development turned out to be inefficient and problematic for software development teams. As software development is different from other kinds of projects e.g. building a house, where every detail has been planned in advance, software oriented projects can constantly change along with the needs of the customer. It can be difficult and complicated to describe to a programmer which functions you want in a program and how they should work and more than often the outcome of the project does not satisfy the customers need.		In the early days of software development, the usual waterfall method used for product development turned out to be inefficient and problematic for software development teams. As software development is different from other kinds of projects e.g. building a house, where every detail has been planned in advance, software oriented projects can constantly change along with the needs of the customer. It can be difficult and complicated to describe to a programmer which functions you want in a program and how they should work and more than often the outcome of the project does not satisfy the customers need.
	It was therefore necessary to come up with a new method more fitted to the ever changing environment of software development projects. The method developed is called Scrum and is an iterative agile software development framework. By being agile, Scrum ensures that everyone involved in the task know where the project stands, what tasks are left and status of ongoing tasks. Scrum encourages the team to share knowledge and help other members in the team to finish the task as fast as possible i.e. Scrum is focused on fast output of tasks and adapting to changes in demand from the client or market. The output of the project is therefore a customized solution which fulfills all of the client's needs.		It was therefore necessary to come up with a new method more fitted to the ever changing environment of software development projects. The method developed is called Scrum and is an iterative agile software development framework. By being agile, Scrum ensures that everyone involved in the task know where the project stands, what tasks are left and status of ongoing tasks. Scrum encourages the team to share knowledge and help other members in the team to finish the task as fast as possible i.e. Scrum is focused on fast output of tasks and adapting to changes in demand from the client or market. The output of the project is therefore a customized solution which fulfills all of the client's needs.

S150892: /* Further Reading */

2016-09-26T18:42:37Z

S150892: /* Application */

2016-09-26T18:15:52Z

Application

← Older revision		Revision as of 18:15, 26 September 2016
Line 83:		Line 83:
	The Scrum Board is important as it monitors the progress of the project. On it, the Product Owner can see which tasks are done and which tasks need to be done to finish the project. The progress is then charted as a Burndown Chart which gives an estimate for the completion of the project. The board is continuously updated along with the projects alterations so that it represents the correct information for each daily meeting.		The Scrum Board is important as it monitors the progress of the project. On it, the Product Owner can see which tasks are done and which tasks need to be done to finish the project. The progress is then charted as a Burndown Chart which gives an estimate for the completion of the project. The board is continuously updated along with the projects alterations so that it represents the correct information for each daily meeting.

	After the Sprint a Sprint Review meeting is held. There the stakeholders and the Development Team come together and review what Increments have been done during the sprint and identify improvements or problems with the items in Product Backlog. These ~~meeting serves~~ mainly as a feedback for the Development Team and to get a overview of the status of the project, which items are done and the remaining tasks of the project. If the Development Team was not able to finish all the items in the Sprint, The team needs to clarify the reason why it is not finished to the Product Owner. The outcome of this meeting is then used as a basis for the next Sprint Plan.		After the Sprint a Sprint Review meeting is held. There the stakeholders and the Development Team come together and review what Increments have been done during the sprint and identify improvements or problems with the items in Product Backlog. These meetings serve mainly as an feedback for the Development Team and to get a overview of the status of the project, which items are done and the remaining tasks of the project. If the Development Team was not able to finish all the items in the Sprint, The team needs to clarify the reason why it is not finished to the Product Owner. The outcome of this meeting is then used as a basis for the next Sprint Plan.

	A Sprint Retrospective is then held to improve the overall process of Scrum of the team. Improvements and problems are identified and are implemented/resolved in the next Sprint Plan. After the retrospective the team is finally ready for the next iteration of the project.		A Sprint Retrospective is then held to improve the overall process of Scrum of the team. Improvements and problems are identified and are implemented/resolved in the next Sprint Plan. After the retrospective the team is finally ready for the next iteration of the project.

S150892: /* Burndown Chart */

2016-09-26T18:13:10Z

Burndown Chart

← Older revision		Revision as of 18:13, 26 September 2016
Line 75:		Line 75:

	===Burndown Chart===		===Burndown Chart===
	A Burndown Chart is a graph which estimates the time length of the project. On the Y-Axis ~~are~~ sum of task estimates the project and on the X-Axis is the time until the project is finished.		A Burndown Chart is a graph which estimates the time length of the project. On the Y-Axis is the sum of task estimates of the project and on the X-Axis is the time until the project is finished.

	==Application==		==Application==

S150892: /* Burndown Chart */

2016-09-26T18:09:14Z

Burndown Chart

← Older revision		Revision as of 18:09, 26 September 2016
Line 75:		Line 75:

	===Burndown Chart===		===Burndown Chart===
	A ~~Burndow~~ Chart is a graph which estimates the time length of the project. On the Y-Axis are sum of task estimates the project and on the X-Axis is the time until the project is finished.		A Burndown Chart is a graph which estimates the time length of the project. On the Y-Axis are sum of task estimates the project and on the X-Axis is the time until the project is finished.

	==Application==		==Application==

S150892: /* Product Backlog */

2016-09-26T18:08:04Z

Product Backlog

← Older revision		Revision as of 18:08, 26 September 2016
Line 48:		Line 48:
	The Product Backlog is a list of tasks that need to be done in order for the product to be developed or changed. It includes all functions, technologies, requirements, enhancements fixes and features that the product should consist of. The items in the backlog have a description, order, estimations and value. <ref name=scrumguide2> [http://www.methodsandtools.com/archive/archive.php?id=18 Adaptive Project Management Using Scrum. (2004) Murpy,Craig (Read 14.09.2016)</ref><ref name=scrumguide></ref>		The Product Backlog is a list of tasks that need to be done in order for the product to be developed or changed. It includes all functions, technologies, requirements, enhancements fixes and features that the product should consist of. The items in the backlog have a description, order, estimations and value. <ref name=scrumguide2> [http://www.methodsandtools.com/archive/archive.php?id=18 Adaptive Project Management Using Scrum. (2004) Murpy,Craig (Read 14.09.2016)</ref><ref name=scrumguide></ref>

	The tasks are generated from User stories which originate from the ~~customers~~ requirements. The Product Backlog is prioritized by the Scrum Master and the Product Owner (who is responsible for the Backlog) so that the project/product generates as much value as possible. <ref name=scrumguide></ref><ref name=scrumguide2> </ref>		The tasks are generated from User stories which originate from the customer requirements. The Product Backlog is prioritized by the Scrum Master and the Product Owner (who is responsible for the Backlog) so that the project/product generates as much value as possible. <ref name=scrumguide></ref><ref name=scrumguide2> </ref>

	As Scrum is an agile framework which consists of using only the known requirements, the Product Backlog is never complete. It keeps on evolving along with the project itself i.e. it behaves dynamically along with the product needs.<ref name=scrumguide></ref><ref name=scrumguide2> </ref>		As Scrum is an agile framework which consists of using only the known requirements, the Product Backlog is never complete. It keeps on evolving along with the project itself i.e. it behaves dynamically along with the product needs.<ref name=scrumguide></ref><ref name=scrumguide2> </ref>

S150892: /* The Product Owner */

2016-09-26T18:01:16Z

The Product Owner

← Older revision		Revision as of 18:01, 26 September 2016
Line 31:		Line 31:
	The Product Owner is the key stakeholder of the project and is responsible for maximizing the value and getting the most out the Development team. The key is that the Product owner has a vision of what the stake holders want the outcome of the project to be and he conveys that vision to the development team by using the product backlog.<ref name=productowner> [https://www.mountaingoatsoftware.com/agile/scrum/product-owner Product Owner. (2016) Mountain Goat Software (Read 14.09.2016) </ref> <ref name=scrumguide></ref>		The Product Owner is the key stakeholder of the project and is responsible for maximizing the value and getting the most out the Development team. The key is that the Product owner has a vision of what the stake holders want the outcome of the project to be and he conveys that vision to the development team by using the product backlog.<ref name=productowner> [https://www.mountaingoatsoftware.com/agile/scrum/product-owner Product Owner. (2016) Mountain Goat Software (Read 14.09.2016) </ref> <ref name=scrumguide></ref>

	He must have a good understanding of the needs of the customer, the marketplace, the competition and how the future can ~~effect~~ the current project.<ref name=productowner></ref>		He must have a good understanding of the needs of the customer, the marketplace, the competition and how the future can affect the current project.<ref name=productowner></ref>

	His role is not to have a decisive factor in how much work should be done, but rather to motivate the team to perform at its greatest by giving them a clear elevating goal. The Development team itself chooses how much work to be done in each sprint, as they withhold the knowledge of how much work can be done in each Sprint and how time consuming tasks can be.<ref name=productowner></ref>		His role is not to have a decisive factor in how much work should be done, but rather to motivate the team to perform at its greatest by giving them a clear elevating goal. The Development team itself chooses how much work to be done in each sprint, as they withhold the knowledge of how much work can be done in each Sprint and how time consuming tasks can be.<ref name=productowner></ref>

S150892: /* Concept */

2016-09-26T17:58:39Z

Concept

← Older revision		Revision as of 17:58, 26 September 2016
Line 11:		Line 11:
	To gather as much knowledge as possible Scrum uses an iterative, feedback driven approach to control risk and optimize predictability which is supported by three pillars made of transparency, inspection and adaption. These iterations are called Sprints and are usually 2-4 weeks long. Before each sprint, a meeting called Sprint Planning is held were the Development Team decides which items from the Product Backlog should be done in the upcoming Sprint. When the sprint is done, a Sprint Review is held with the purpose to see which Increments have been added to the solution, what problems were encountered in the Sprint and to receive feedback for the work done in the Sprint. This process then repeats itself until the project is finished. <ref name = scrumguide></ref>		To gather as much knowledge as possible Scrum uses an iterative, feedback driven approach to control risk and optimize predictability which is supported by three pillars made of transparency, inspection and adaption. These iterations are called Sprints and are usually 2-4 weeks long. Before each sprint, a meeting called Sprint Planning is held were the Development Team decides which items from the Product Backlog should be done in the upcoming Sprint. When the sprint is done, a Sprint Review is held with the purpose to see which Increments have been added to the solution, what problems were encountered in the Sprint and to receive feedback for the work done in the Sprint. This process then repeats itself until the project is finished. <ref name = scrumguide></ref>

	To document the projects progress, as visual tool called a Scrum Board is used to display where the project stands. This visually represents every ~~tasks~~ that needs to be done, has been done or is in progress.		To document the projects progress, as visual tool called a Scrum Board is used to display where the project stands. This visually represents every task that needs to be done, has been done or is in progress.

	==Scrum Values==		==Scrum Values==

S150892 at 17:55, 26 September 2016

2016-09-26T17:55:55Z

← Older revision		Revision as of 17:55, 26 September 2016
Line 1:		Line 1:
	In the early days of software development, the usual waterfall method used for product development turned out to be inefficient and problematic for software development teams. As software development is different from other kinds of projects e.g. building a house, where every detail has been planned in advance, software oriented projects can constantly change along with the needs of the customer. It can be difficult and complicated to describe to a programmer which functions you want in a program and how they should work and more than often the outcome of the project does not satisfy the customers need.		In the early days of software development, the usual waterfall method used for product development turned out to be inefficient and problematic for software development teams. As software development is different from other kinds of projects e.g. building a house, where every detail has been planned in advance, software oriented projects can constantly change along with the needs of the customer. It can be difficult and complicated to describe to a programmer which functions you want in a program and how they should work and more than often the outcome of the project does not satisfy the customers need.
	It was therefore necessary to come up with a new method more fitted to the ever changing environment of software development projects. The method developed is called Scrum and is an iterative agile software development framework. By being agile, Scrum ensures that everyone involved in the task know where the project stands, what tasks are left and status of ongoing tasks. Scrum encourages the team to share knowledge and help other members in the team to finish the task as fast as possible i.e. Scrum is focused on fast output of tasks and adapting to changes in demand from the client or market. The output of the project is therefore a customized solution which fulfills all of the ~~clients~~ needs.		It was therefore necessary to come up with a new method more fitted to the ever changing environment of software development projects. The method developed is called Scrum and is an iterative agile software development framework. By being agile, Scrum ensures that everyone involved in the task know where the project stands, what tasks are left and status of ongoing tasks. Scrum encourages the team to share knowledge and help other members in the team to finish the task as fast as possible i.e. Scrum is focused on fast output of tasks and adapting to changes in demand from the client or market. The output of the project is therefore a customized solution which fulfills all of the client's needs.
	==History==		==History==
	The initial concept of Scrum was developed by Hirotaka Takeuchi and Ikujiro Nonaka in their paper "The New New Product Development Game" which they published in 1986. In it, they came up with a new faster and more flexible approach to managing product development processes. They described it using a rugby team, where the team passes the ball within to reach a common goal or in other words, the project team works together and help each other to reach the projects goal. In it they argue that teams do better when given goals instead of the usual tasks. The team would then figure out how to reach the goal and overcome obstacles to reach the goal in the most efficient way. <ref> [https://hbr.org/1986/01/the-new-new-product-development-game The New New Product Development Game. (1986) Takeuchi and Nonaka (Read 13.09.16).</ref>		The initial concept of Scrum was developed by Hirotaka Takeuchi and Ikujiro Nonaka in their paper "The New New Product Development Game" which they published in 1986. In it, they came up with a new faster and more flexible approach to managing product development processes. They described it using a rugby team, where the team passes the ball within to reach a common goal or in other words, the project team works together and help each other to reach the projects goal. In it they argue that teams do better when given goals instead of the usual tasks. The team would then figure out how to reach the goal and overcome obstacles to reach the goal in the most efficient way. <ref> [https://hbr.org/1986/01/the-new-new-product-development-game The New New Product Development Game. (1986) Takeuchi and Nonaka (Read 13.09.16).</ref>

S150892: /* Agile Scrum in relation to Non-Software Projects */

2016-09-25T12:02:15Z

Agile Scrum in relation to Non-Software Projects

← Older revision		Revision as of 12:02, 25 September 2016
Line 123:		Line 123:

	*Define ''Working Software'': Deliverables that create value for the customer are not always a functional software. It can be for an instance a new process or a roadmap.		*Define ''Working Software'': Deliverables that create value for the customer are not always a functional software. It can be for an instance a new process or a roadmap.
	*Define ''Customer'': When thinking about software, the customer is usually the front end user, but in the non-software world, identifying the customer can be challenging. The customer is typically the ~~stakeholders~~ of the project but often they have conflicting interests and priorities. Choosing the right Product Owner is then critical as he can help ~~balancing~~ those interests.		*Define ''Customer'': When thinking about software, the customer is usually the front end user, but in the non-software world, identifying the customer can be challenging. The customer is typically the stakeholder/s of the project but often they have conflicting interests and priorities. Choosing the right Product Owner is then critical as he can help balance those interests.
	*Define ''Done'': To figure out when each deliverable is done, cooperation is needed between the product owner and the sponsors. It is important to set a criteria when a deliverable is a success.		*Define ''Done'': To figure out when each deliverable is done, cooperation is needed between the product owner and the sponsors. It is important to set a criteria when a deliverable is a success.
	*Measure Business Value: Establishing the business value and measuring it is crucial for every non-software project. Before each iteration, clearly state the cost benefit of going through the iteration and articulate these benefits after each iteration. Metrics for measuring these non-project initiatives should be defined beforehand.		*Measure Business Value: Establishing the business value and measuring it is crucial for every non-software project. Before each iteration, clearly state the cost benefit of going through the iteration and articulate these benefits after each iteration. Metrics for measuring these non-project initiatives should be defined beforehand.

← Older revision		Revision as of 18:42, 26 September 2016
Line 129:		Line 129:

	==Further Reading==		==Further Reading==
	''Scrum Is Not Just For Software'' by Robbie Mac Iver: This ~~articel~~ goes through some key points on how and why Scrum can be implemented in the majority of projects.		*''Scrum Is Not Just For Software'' by Robbie Mac Iver: This article goes through some key points on how and why Scrum can be implemented in the majority of projects.
			*''Agile Retrospective, Making Good Teams Great'' by Esther Derby and Diana Larsen. Goes through problems that can come up during the Scrum process and how to deal with them appropriately and overall enhance the Scrum experience of the whole team.
			*''Agile Project Management With Scrum'' by Ken Schwaber. Ken Schwaber gives an excellent explanation of the theory of Scrum and how to implement it in real life scenarios.

	==References==		==References==
	<references />		<references />