Scrum an Agile Framework - Revision history

Tkokotas at 14:13, 18 December 2018

2018-12-18T14:13:36Z

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

	[[File:Scrum framework.jpg‎\|400px\|right\|thumb\|Scrum Framwork<ref name=scrumimage>Yelkar, Kshitij. Scrum Framework. 2015. Web. 16 Sept. 2016.</ref>]]		[[File:Scrum framework.jpg‎\|400px\|right\|thumb\|Scrum Framwork<ref name=scrumimage>Yelkar, Kshitij. Scrum Framework. 2015. Web. 16 Sept. 2016.</ref>]]

S150948 at 19:10, 26 September 2016

2016-09-26T19:10:17Z

← Older revision		Revision as of 19:10, 26 September 2016
Line 122:		Line 122:
	==Scrum in projects not concerning software development==		==Scrum in projects not concerning software development==
	There is nothing that says Scrum can not be applied to projects other than for software development, Scrum can be used in all types of projects. But Scrum does not always fit the project even though it can be applied. The Scrum method is time-consuming and costly, with meetings every day and constantly planning and reviewing the work plan. If the project fits the points mentioned before (See Is Scrum For Me?) most likely Scrum can be applied.		There is nothing that says Scrum can not be applied to projects other than for software development, Scrum can be used in all types of projects. But Scrum does not always fit the project even though it can be applied. The Scrum method is time-consuming and costly, with meetings every day and constantly planning and reviewing the work plan. If the project fits the points mentioned before (See Is Scrum For Me?) most likely Scrum can be applied.

			=Further Reading=

			If interested in learning more about Scrum, http://www.scrum-institute.org/index.php provides an insight in the Scrum universe and offers free training in the art of Scrum.

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

S150948: /* The Development Team */

2016-09-26T19:08:10Z

The Development Team

← Older revision		Revision as of 19:08, 26 September 2016
Line 42:		Line 42:

	==The Development Team==		==The Development Team==
	After the Product Owner and the Scrum Master have done their work in the planning process, it is up to the Development Team to complete the tasks and come up with a solution that satisfies the requirements set by the Product Owner. The importance of the Scrum framework is that the Development Team is a '''team''', they as a team are responsible if something that goes wrong or if something is done well, not a single individual. The Development Team are cross-functional so they have the knowledge and experience to complete the tasks they are assigned to. Generally, the team consists of 3-9 members, if there are too few, the tasks may not be completed and too many can lead to management issues. As noted before the Product Owner does not hand out detailed work plans regarding each task, the Development Team reviews each task before each sprint and divides it into more tasks and estimates the work time needed for each task. The Development Team is responsible for completing those tasks and hand out a shippable product at the end of each sprint*.<ref>"Scrum Roles – The Scrum Team - International Scrum Institute". Scrum-institute.org. Web. 16 Sept. 2016.</ref><ref name=scrumroles>"Scrum Roles". agile42. Web. 15 Sept. 2016.</ref>		After the Product Owner and the Scrum Master have done their work in the planning process, it is up to the Development Team to complete the tasks and come up with a solution that satisfies the requirements set by the Product Owner. The importance of the Scrum framework is that the Development Team is a '''team''', they as a team are responsible if something that goes wrong or if something is done well, not a single individual. The Development Team are cross-functional so they have the knowledge and experience to complete the tasks they are assigned to. Generally, the team consists of 3-9 members, if there are too few, the tasks may not be completed and too many can lead to management issues. As noted before the Product Owner does not hand out detailed work plans regarding each task, the Development Team reviews each task before each sprint and divides it into more tasks and estimates the work time needed for each task. The Development Team is responsible for completing those tasks and hand out a shippable product at the end of each sprint.<ref>"Scrum Roles – The Scrum Team - International Scrum Institute". Scrum-institute.org. Web. 16 Sept. 2016.</ref><ref name=scrumroles>"Scrum Roles". agile42. Web. 15 Sept. 2016.</ref>

	*A Sprint is an iterative process where work is split into different periods, from one week up to 30 days at a time. In each Sprint, the team focuses on completing the tasks in that Sprint and make them ready ~~for reviewing~~.		*A Sprint is an iterative process where work is split into different periods, from one week up to 30 days at a time. In each Sprint, the team focuses on completing the tasks in that Sprint and make them ready so they can be presented and reviewed.

	=The Scrum Plan=		=The Scrum Plan=

S150948: /* The Development Team */

2016-09-26T19:06:56Z

The Development Team

← Older revision		Revision as of 19:06, 26 September 2016
Line 42:		Line 42:

	==The Development Team==		==The Development Team==
	After the Product Owner and the Scrum Master have done their work in the planning process, it is up to the Development Team to complete the tasks and come up with a solution that satisfies the requirements set by the Product Owner. The importance of the Scrum framework is that the Development Team is a '''team''', they as a team are responsible if something that goes wrong or if something is done well, not a single individual. The Development Team are cross-functional so they have the knowledge and experience to complete the tasks they are assigned to. Generally, the team consists of 3-9 members, if there are too few, the tasks may not be completed and too many can lead to management issues. As noted before the Product Owner does not hand out detailed work plans regarding each task, the Development Team reviews each task before each sprint and divides it into more tasks and estimates the work time needed for each task. The Development Team is responsible for completing those tasks and hand out a shippable product at the end of each sprint.<ref>"Scrum Roles – The Scrum Team - International Scrum Institute". Scrum-institute.org. Web. 16 Sept. 2016.</ref><ref name=scrumroles>"Scrum Roles". agile42. Web. 15 Sept. 2016.</ref>		After the Product Owner and the Scrum Master have done their work in the planning process, it is up to the Development Team to complete the tasks and come up with a solution that satisfies the requirements set by the Product Owner. The importance of the Scrum framework is that the Development Team is a '''team''', they as a team are responsible if something that goes wrong or if something is done well, not a single individual. The Development Team are cross-functional so they have the knowledge and experience to complete the tasks they are assigned to. Generally, the team consists of 3-9 members, if there are too few, the tasks may not be completed and too many can lead to management issues. As noted before the Product Owner does not hand out detailed work plans regarding each task, the Development Team reviews each task before each sprint and divides it into more tasks and estimates the work time needed for each task. The Development Team is responsible for completing those tasks and hand out a shippable product at the end of each sprint*.<ref>"Scrum Roles – The Scrum Team - International Scrum Institute". Scrum-institute.org. Web. 16 Sept. 2016.</ref><ref name=scrumroles>"Scrum Roles". agile42. Web. 15 Sept. 2016.</ref>

			*A Sprint is an iterative process where work is split into different periods, from one week up to 30 days at a time. In each Sprint, the team focuses on completing the tasks in that Sprint and make them ready for reviewing.

	=The Scrum Plan=		=The Scrum Plan=

S150948 at 18:48, 26 September 2016

2016-09-26T18:48:58Z

Show changes

S150948: /* Is Scrum for me? */

2016-09-16T19:53:49Z

Is Scrum for me?

← Older revision		Revision as of 19:53, 16 September 2016
Line 116:		Line 116:
	*If the deadline of the project is more than a couple of years, Scrum is costly		*If the deadline of the project is more than a couple of years, Scrum is costly

	After going over these points and you have decided that the Scrum Framework is suitable, the first thing to do is assemble the team. Starting with the Product Owner, assigning an Product Owner can be the most vital decision to make, because he is the one responsible for maximizing the value of the project and interpret what the customer wants and needs from the product. Next up is the Scrum Master, the Scrum Master must be willing to follow the Scrum Framework at all times and aid the team members and mentor them in the art of Scrum. You do not have to assemble the Development Team in the start, as the project is still in the planning stages and the requirements are not clear. The Development Team has to be ready before the first Sprint, and have the knowledge and skill to deliver a successful project. When the Scrum team is assembled, a Sprint planning meeting is held, which takes the most vital Product Backlog tasks and plans the work for the next Sprint. A Scrum board is created to provide an overview of the project along with the Burndown Chart. The tasks in the Sprint are not supposed to be changed, but often times unpredictable events can lead to changes and the team has to be able to react accordingly. By modifying the Sprint or cancelling it of needed (the Product Owner is the only one with authority to do so). After the Sprint (usually 2-4 weeks), there is a Sprint review. During the Sprint review the team demos what work has been done and gets feedback if any. After the Sprint review, the team hold a Sprint retrospective meeting to reflect on what happened during the recently finished Sprint to improve the future Sprints. This process continues in iterations (2-4 weeks) until the project is finished, that is a new Sprint planning meeting is held at the beginning of each Sprint, next the Sprint is reviewed and a Sprint retrospective meeting is held after the review.		After going over these points and you have decided that the Scrum Framework is suitable, the first thing to do is assemble the team. Starting with the Product Owner, assigning a Product Owner can be the most vital decision to make, because he is the one responsible for maximizing the value of the project and interpret what the customer wants and needs from the product. Next up is the Scrum Master, the Scrum Master must be willing to follow the Scrum Framework at all times and aid the team members and mentor them in the art of Scrum. You do not have to assemble the Development Team in the start, as the project is still in the planning stages and the requirements are not clear. The Development Team has to be ready before the first Sprint, and have the knowledge and skill to deliver a successful project. When the Scrum team is assembled, a Sprint planning meeting is held, which takes the most vital Product Backlog tasks and plans the work for the next Sprint. A Scrum board is created to provide an overview of the project along with the Burndown Chart. The tasks in the Sprint are not supposed to be changed, but often times unpredictable events can lead to changes and the team has to be able to react accordingly. By modifying the Sprint or cancelling it of needed (the Product Owner is the only one with authority to do so). After the Sprint (usually 2-4 weeks), there is a Sprint review. During the Sprint review the team demos what work has been done and gets feedback if any. After the Sprint review, the team hold a Sprint retrospective meeting to reflect on what happened during the recently finished Sprint to improve the future Sprints. This process continues in iterations (2-4 weeks) until the project is finished, that is a new Sprint planning meeting is held at the beginning of each Sprint, next the Sprint is reviewed and a Sprint retrospective meeting is held after the review.


	==Scrum in projects not concerning software development==		==Scrum in projects not concerning software development==

S150948: /* Sprint Burndown Chart */

2016-09-16T19:52:17Z

Sprint Burndown Chart

← Older revision		Revision as of 19:52, 16 September 2016
Line 90:		Line 90:
	==Sprint Burndown Chart==		==Sprint Burndown Chart==
	[[File:Reading-burn-down-chart2.png‎\|400px\|right\|thumb\|Example of a Burndown Chart<ref>Wenzel, Joel. Burndown Chart. Web. 16 Sept. 2016.</ref>]]		[[File:Reading-burn-down-chart2.png‎\|400px\|right\|thumb\|Example of a Burndown Chart<ref>Wenzel, Joel. Burndown Chart. Web. 16 Sept. 2016.</ref>]]
	Is a chart to ~~monitors~~ progress throughout the ~~sprint~~, it displays the progress remaining in the ~~sprint~~. The x axis represent the time of the ~~sprint~~ (usually in days) and the y axis represent the work remaining. There is a line on the chart showing the effort remaining and often another line showing the ideal effort of the team. The ideal effort line can help the team see where they stand if they are above the line means that they are behind schedule. This can be because the team did not make an accurate estimate or that the task has changed during the ~~sprint~~, if there are drastic changes to the ~~sprint~~ that affects the progress of the ~~sprint~~ the Product Owner has authority to cancel the ~~sprint~~ if needed. If the team is ahead of schedule the remaining effort line is under the ideal effort line.		Is a chart to monitor progress throughout the Sprint, it displays the progress remaining in the Sprint. The x axis represent the time of the Sprint (usually in days) and the y axis represent the work remaining. There is a line on the chart showing the effort remaining and often another line showing the ideal effort of the team. The ideal effort line can help the team see where they stand if they are above the line means that they are behind schedule. This can be because the team did not make an accurate estimate or that the task has changed during the Sprint, if there are drastic changes to the Sprint that affects the progress of the Sprint the Product Owner has authority to cancel the Sprint if needed. If the team is ahead of schedule the remaining effort line is under the ideal effort line.

	=Implementing Scrum=		=Implementing Scrum=

S150948: /* Sprint Backlog */

2016-09-16T19:51:22Z

Sprint Backlog

← Older revision		Revision as of 19:51, 16 September 2016
Line 78:		Line 78:


	The ~~sprint backlog~~ contains a list of items the from the ~~product backlog~~, usually the items with the highest priority end up in the ~~sprint backlog~~. The items in the ~~sprint backlog~~ are selected by the team and the team should not select more items than they can handle each ~~sprint~~, because the team is trying to complete all the tasks in each ~~sprint~~. After the team has selected the number of items from the ~~product backlog~~, each item is divided into more tasks and an estimate is made.<ref>"Sprint Backlog". Scrum Inc. N.p., 2014. Web. 16 Sept. 2016.</ref> The estimate is given in story points, story points are used to measure the effort needed to finish a specific task. The story point scale can be different between teams, the scale can be; 1,3,5,8,13,40,11 or xsmall, small, large, xlarge e.g. Note the story points are not measured in hours.<ref>"Scrum Effort Estimation And Story Points". Scrummethodology.com. Web. 16 Sept. 2016.</ref> The Sprint Backlog is often represented with a Scrum ~~board~~. The Scrum ~~board~~ provides an overview of all the Product Backlog tasks and the Sprint Backlog tasks within the Sprint. Often the board has 5 columns; The Product Backlog tasks column, a to-do column showing all the Sprint Backlog tasks, an in progress column showing all the Sprint Backlog tasks that are in progress, a test column where completed tasks are waiting to be tested and finally a done column showing the completed Sprint Backlog tasks. The Scrum ~~board~~ can be in the form of a paper board that is available in the team room or a digital board on a website, often the team is using both forms.		The Sprint Backlog contains a list of items the from the Product Backlog, usually the items with the highest priority end up in the Sprint Backlog. The items in the Sprint Backlog are selected by the team and the team should not select more items than they can handle each Sprint, because the team is trying to complete all the tasks in each Sprint. After the team has selected the number of items from the Product Backlog, each item is divided into more tasks and an estimate is made.<ref>"Sprint Backlog". Scrum Inc. N.p., 2014. Web. 16 Sept. 2016.</ref> The estimate is given in story points, story points are used to measure the effort needed to finish a specific task. The story point scale can be different between teams, the scale can be; 1,3,5,8,13,40,11 or xsmall, small, large, xlarge e.g. Note the story points are not measured in hours.<ref>"Scrum Effort Estimation And Story Points". Scrummethodology.com. Web. 16 Sept. 2016.</ref> The Sprint Backlog is often represented with a Scrum Board. The Scrum Board provides an overview of all the Product Backlog tasks and the Sprint Backlog tasks within the Sprint. Often the board has 5 columns; The Product Backlog tasks column, a to-do column showing all the Sprint Backlog tasks, an in progress column showing all the Sprint Backlog tasks that are in progress, a test column where completed tasks are waiting to be tested and finally a done column showing the completed Sprint Backlog tasks. The Scrum Board can be in the form of a paper board that is available in the team room or a digital board on a website, often the team is using both forms.
	===Planning Poker===		===Planning Poker===
	To estimate the story points a common method is used called planning poker. As the name implies it is builds on the poker principles, every team member gets a set of cards, on each card there is a story point e.g. there can be 7 cards if the scale is 1,3,5,8,13,40,100. The team goes over each task in the ~~sprint backlog~~ and gives an estimate of how many story points that specific task needs. The purpose of the planning poker is that each team member selects a card that only he can see and the team reveals the card they chose at the same time. This ensures that the estimate is not affected by other team members. If a team member has an estimate that is different than the majority, either too low or too high, the team member gets a chance to explain the reason for that estimate. If the team does not agree on the number of story points for a specific task, a discussion takes place until every team member is satisfied with the number of story points. Often the team member assigned to the task has more influence on the estimate than other team members.		To estimate the story points a common method is used called planning poker. As the name implies it is builds on the poker principles, every team member gets a set of cards, on each card there is a story point e.g. there can be 7 cards if the scale is 1,3,5,8,13,40,100. The team goes over each task in the Sprint Backlog and gives an estimate of how many story points that specific task needs. The purpose of the planning poker is that each team member selects a card that only he can see and the team reveals the card they chose at the same time. This ensures that the estimate is not affected by other team members. If a team member has an estimate that is different than the majority, either too low or too high, the team member gets a chance to explain the reason for that estimate. If the team does not agree on the number of story points for a specific task, a discussion takes place until every team member is satisfied with the number of story points. Often the team member assigned to the task has more influence on the estimate than other team members.

	'''Example''':		'''Example''':

S150948: /* Product Backlog */

2016-09-16T19:48:52Z

Product Backlog

← Older revision		Revision as of 19:48, 16 September 2016
Line 72:		Line 72:
	[[File:Product Backlog.jpg‎\|150px\|right\|thumb\|Product Backlog<ref name=scrumimage />]]		[[File:Product Backlog.jpg‎\|150px\|right\|thumb\|Product Backlog<ref name=scrumimage />]]

	The ~~product backlog~~ contains a list of items that the Product Owner and the Scrum Master have made after interpreting the customer needs. It is a to-do list of what needs to be done in order to deliver a successful product. The items in the list are prioritized to maximize the return of investment and are only added to the ~~product backlog~~ if they add value to the project. The team estimates how long each task will take during the ~~sprint review~~ and divide each task into smaller tasks, as the requirements can be changing throughout the project, the list is constantly changing. Whether new items are added or current items are modified. As the ~~product backlog~~ changes throughout the project, the level of detail of each task is different. Tasks that are not in the next couple of ~~sprints~~ have a brief description of what is needed and tasks that are in the next couple of ~~sprints~~ have a more detailed description. With having lower level of detail in tasks that are not in the current sprint, prevents time consuming processes in acquiring requirements and needs for that task and the requirements can change over time. The Product Owner is responsible for maintaining and changing the ~~product backlog~~.<ref>"The Scrum Product Backlog - International Scrum Institute". Scrum-institute.org. Web. 16 Sept. 2016.</ref>		The Product Backlog contains a list of items that the Product Owner and the Scrum Master have made after interpreting the customer needs. It is a to-do list of what needs to be done in order to deliver a successful product. The items in the list are prioritized to maximize the return of investment and are only added to the Product Backlog if they add value to the project. The team estimates how long each task will take during the Sprint Review and divide each task into smaller tasks, as the requirements can be changing throughout the project, the list is constantly changing. Whether new items are added or current items are modified. As the Product Backlog changes throughout the project, the level of detail of each task is different. Tasks that are not in the next couple of Sprints have a brief description of what is needed and tasks that are in the next couple of Sprints have a more detailed description. With having lower level of detail in tasks that are not in the current sprint, prevents time consuming processes in acquiring requirements and needs for that task and the requirements can change over time. The Product Owner is responsible for maintaining and changing the Product Backlog.<ref>"The Scrum Product Backlog - International Scrum Institute". Scrum-institute.org. Web. 16 Sept. 2016.</ref>

	==Sprint Backlog==		==Sprint Backlog==

S150948: /* Sprint Retrospective */

2016-09-16T19:47:33Z

Sprint Retrospective

← Older revision		Revision as of 19:47, 16 September 2016
Line 66:		Line 66:

	==Sprint Retrospective==		==Sprint Retrospective==
	The meeting usually takes place after the ~~sprint review~~, the Scrum Master is responsible that the meetings takes place. The team discusses the recently completed ~~sprint~~ and how the experience gained from it can help in improving future ~~sprints~~.		The meeting usually takes place after the Sprint Review, the Scrum Master is responsible that the meetings takes place. The team discusses the recently completed Sprint and how the experience gained from it can help in improving future Sprints.

	=Artifacts=		=Artifacts=