Agile Project Management with SCRUM
| Line 2: | Line 2: | ||
First agile project management (APM) methodologies were created and implemented in the early 1990s, especially for IT projects, mainly cause of the fast-changing project environment. In the manifesto of agile software development, the following key values for APM are defined: " Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan"<ref>Manifesto for Agile Software Development, ''Agilemanifesto.org '', (Accessed on 6th of February), </ref>. | First agile project management (APM) methodologies were created and implemented in the early 1990s, especially for IT projects, mainly cause of the fast-changing project environment. In the manifesto of agile software development, the following key values for APM are defined: " Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan"<ref>Manifesto for Agile Software Development, ''Agilemanifesto.org '', (Accessed on 6th of February), </ref>. | ||
| − | The overall goal is to reduce complexity in the development of projects, to support a quick implementation in an inexpensive and high-quality way according the customer needs. Furthermore, a key characteristic of APM is the high level of responsiveness to changes as well as continuous Stakeholder involvements over the whole project duration <ref name="guide">Project Management Institute, ''A Guide to Project Management Body of Knowledge'', (Project Management Institute, 2013), </ref>. The SCRUM agile project management approach is the dominant methodology used in the practical context and was introduced by Nonaka and Takeuchi in their "new product development Game". It is designed to guide team in the iterative and incremental delivery of a product. In the following article the overall SCRUM process is described with its roles, meetings and rules. In addition, a comparison between the traditional "old-school" project management approach and APM Scrum is executed and the benefits as well as limitations of the SCRUM methodology are discovered and critically analyzed. | + | The overall goal is to reduce complexity in the development of projects, to support a quick implementation in an inexpensive and high-quality way according the customer needs. Furthermore, a key characteristic of APM is the high level of responsiveness to changes as well as continuous Stakeholder involvements over the whole project duration <ref name="guide">Project Management Institute, ''A Guide to Project Management Body of Knowledge'', (Project Management Institute, 2013), </ref>. The SCRUM agile project management approach is the dominant methodology used in the practical context and was introduced by Nonaka and Takeuchi in their "new product development Game" <ref name="Takuchi">Takuchi, H. & Nonaka I., ''The new product development game'', (Harvard Business Review, 1986), </ref>.. It is designed to guide team in the iterative and incremental delivery of a product. In the following article the overall SCRUM process is described with its roles, meetings and rules. In addition, a comparison between the traditional "old-school" project management approach and APM Scrum is executed and the benefits as well as limitations of the SCRUM methodology are discovered and critically analyzed. |
| Line 9: | Line 9: | ||
===SCRUM Process=== | ===SCRUM Process=== | ||
| + | |||
| + | The Scrum process consists out of four artefacts: product backlog, spring backlog, different sprints and the final product. | ||
| + | The process begins with the product planning meeting, where the product backlog, which include all functionalities and requirements for the product or system as well as the different tasks which have to be executed in order to get the final product, is defined. As the Scrum approach is an agile project management methodology the product backlog is dynamic and never completed and therefore just a rough estimation, which always could be changed during the whole project. Moreover, the Product Backlog prioritizes the different requirements according to their value creation <ref name="guide"/>. In general, the product backlog could be compared with a traditional specification sheet <ref name="sobiech">Sobiech, F., ''Abbildung von Synergiepotenzialen zwischen IT-Anforderungen in Scrum'', (Springer Fachmedien Wiesbaden GmbH, 2016), </ref>.. | ||
| + | The whole project is divided in different cycles, so-called sprints, where the actual work is done <ref name="schwaber">Schwaber, K., ''Agile Project Management with SCRUM'', (Microsoft Press, 2004), </ref>.. Within the sprint planning meeting the sprint backlog is defined . Therefore, as many of the tasks of the before defined Product backlog are transferred to the sprint backlog as the team believe it can turn in to potentially product functionalities at the end of the sprint. The target of each sprint is to create a new product functionality, which can be introduced to the customer and brings the desired benefit. Therefore, the customer is always up-to-date within the whole scrum process and provides continuous feedback which is considered and implemented in the sprints [2]. Normally one task within the sprint backlog does not take longer than 4 to 16 hours. In case a task last longer, it is not well defined. Furthermore, it is important that the sprint backlog is updated on a regular basis. In fact, it might be that the team add or remove assigned tasks from the sprint backlog in order to avoid redundancies. At the end of each sprint a sprint review meeting with the customer and all project stakeholders takes place to discuss the achieved functionality and receive valuable feedback. The sprint process is a repetitive process and last as long until all functionalities and task of the product backlog are implemented and then lead to the final product [5]. | ||
| + | |||
| + | Figure 1 below gives an overview of the complete Scrum Process with its different meetings and artefacts. | ||
Revision as of 19:20, 13 February 2018
First agile project management (APM) methodologies were created and implemented in the early 1990s, especially for IT projects, mainly cause of the fast-changing project environment. In the manifesto of agile software development, the following key values for APM are defined: " Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan"[1].
The overall goal is to reduce complexity in the development of projects, to support a quick implementation in an inexpensive and high-quality way according the customer needs. Furthermore, a key characteristic of APM is the high level of responsiveness to changes as well as continuous Stakeholder involvements over the whole project duration [2]. The SCRUM agile project management approach is the dominant methodology used in the practical context and was introduced by Nonaka and Takeuchi in their "new product development Game" [3].. It is designed to guide team in the iterative and incremental delivery of a product. In the following article the overall SCRUM process is described with its roles, meetings and rules. In addition, a comparison between the traditional "old-school" project management approach and APM Scrum is executed and the benefits as well as limitations of the SCRUM methodology are discovered and critically analyzed.
Contents |
Big Idea
SCRUM Process
The Scrum process consists out of four artefacts: product backlog, spring backlog, different sprints and the final product. The process begins with the product planning meeting, where the product backlog, which include all functionalities and requirements for the product or system as well as the different tasks which have to be executed in order to get the final product, is defined. As the Scrum approach is an agile project management methodology the product backlog is dynamic and never completed and therefore just a rough estimation, which always could be changed during the whole project. Moreover, the Product Backlog prioritizes the different requirements according to their value creation [2]. In general, the product backlog could be compared with a traditional specification sheet [4].. The whole project is divided in different cycles, so-called sprints, where the actual work is done [5].. Within the sprint planning meeting the sprint backlog is defined . Therefore, as many of the tasks of the before defined Product backlog are transferred to the sprint backlog as the team believe it can turn in to potentially product functionalities at the end of the sprint. The target of each sprint is to create a new product functionality, which can be introduced to the customer and brings the desired benefit. Therefore, the customer is always up-to-date within the whole scrum process and provides continuous feedback which is considered and implemented in the sprints [2]. Normally one task within the sprint backlog does not take longer than 4 to 16 hours. In case a task last longer, it is not well defined. Furthermore, it is important that the sprint backlog is updated on a regular basis. In fact, it might be that the team add or remove assigned tasks from the sprint backlog in order to avoid redundancies. At the end of each sprint a sprint review meeting with the customer and all project stakeholders takes place to discuss the achieved functionality and receive valuable feedback. The sprint process is a repetitive process and last as long until all functionalities and task of the product backlog are implemented and then lead to the final product [5].
Figure 1 below gives an overview of the complete Scrum Process with its different meetings and artefacts.
SCRUM Roles
SCRUM Meetings
Application
Comparison between 'old-school' and agile scrum project management
Benefits
Limitations
Annotated bibliography
References
- ↑ Manifesto for Agile Software Development, Agilemanifesto.org , (Accessed on 6th of February),
- ↑ 2.0 2.1 Project Management Institute, A Guide to Project Management Body of Knowledge, (Project Management Institute, 2013),
- ↑ Takuchi, H. & Nonaka I., The new product development game, (Harvard Business Review, 1986),
- ↑ Sobiech, F., Abbildung von Synergiepotenzialen zwischen IT-Anforderungen in Scrum, (Springer Fachmedien Wiesbaden GmbH, 2016),
- ↑ Schwaber, K., Agile Project Management with SCRUM, (Microsoft Press, 2004),
