Agile Project Management with SCRUM

From apppm
Revision as of 20:06, 13 February 2018 by S172691 (Talk | contribs)

Jump to: navigation, search

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.


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 Cite error: Closing </ref> missing for <ref> tag


Cite error: <ref> tags exist, but no <references/> tag was found
Personal tools
Namespaces

Variants
Actions
Navigation
Toolbox