Agile PM with Scrum: A (Very) Short Introduction
We are currently finalizing a new optional module for Onepoint that will allow integrating agile project management based on the Scrum framework into formal PM processes. I thought that this might be a good time to introduce you to the basic concepts behind Scrum and to try to relate these to PMI/IPMA standard terms.
Scrum is an agile project management framework that was originally formalized by Jeff Sutherland and Ken Schwaber in an OOPSLA conference paper in 1995. Both had developed very similar concepts in parallel to each other from the early nineties on. The term "Scrum" itself was already used earlier in a similar context by a number of Japanese researchers and originates from the game rugby (the English hard-core version of american football ;-).
Scrum was initially developed as a way to iteratively develop software, but can basically be applied to any project where an iterative approach makes sense. For instance, a number of companies are starting to use Scrum also for innovation management and other creative projects. You can even use Scrum for external (customer) projects, but in this case you will also need to "mix in" some formal PM techniques.
In my opinion, there are only two basic concepts that provide the foundation for most of the Scrum framework:
- The product backlog consists of a number of prioritized stories (requirements) and is maintained by the product owner. She decides on what story goes into which release and on the importance of each story (roughly, the order of implementation or priority).
- Every Scrum project is divided into sprints of typically three to six weeks lengths each. Each story is estimated in story points (ideal person days) and assigned to exactly one sprint. Within each sprint, the cross-functional team members take the stories from the sprint backlog in the order of importance and implement them (explicit resource assignments on the story/task level are optional). A scrum master (roughly relates to the project manager or work package owner) coordinates each sprint.
In addition, there are a few "tools" that are typically used when Scrum is practiced:
- The sprint planning meeting takes place at the beginning of a sprint and is used to plan the sprint (stories, estimations etc.).
- The task board is used to display all not taken, in progress and completed tasks (often using a whiteboard and post-it notes).
- The burndown chart represents a graph of time (length of the sprint in days on the x-axis) vs. cumulated story points (y-axis) and basically visualizes the velocity of the sprint progress (stories/tasks implemented per day).
- The daily scrum is a daily 15-minute meeting where each team member communicates efficiently what she has achieved the day before, what she will do today and whether there are any problems that need to be solved.
- The sprint review meeting takes place after a spring was completed and should include demoing the sprint's outcome (the product/deliverables) to the project stakeholders (product owner, customer etc.).
The advantages of Scrum over the classical waterfall development model are clearly its agility and flexibility. The resulting overall schedule over a longer period of time is often also more realistic, since individual tasks are not scheduled at all and thus, no unrealistic buffers have been applied (in my opinion, in this way even comparable to Critical Chain PM). In addition, the product owner and even the customer can change requirements between sprints and thus, market dynamics and changes of mind can be incorporated more rapidly and thus, effectively into the development process.
The major disadvantages of Scrum are mainly in the areas of cross-project and resource utilization planning, simply because there are no synchronization points (milestones) and there is typically also no real resource schedule. However, I strongly believe that most of these shortcomings can be solved by applying classical IPMA and PMI techniques one level "above" the Scrum project. And this is exactly what we intend to go after with our new Agile Planning Option (APO) at Onepoint, but more about this in one of the next posts...