Last week we introduced Agile Project Management and explained that Agile is a methodology rather than a framework. That is, Agile is a set of principles that align people around a common language and belief system focused on getting work done. Today we are going to look at the most popular Agile framework, – Scrum. A framework is prescriptive set of tools that help people align with one or more methodologies. Scrum is the leading concept for how to get project based work done in an Agile way.
So what is Scrum actually?
Scrum is a project management toolkit that teaches the following concepts:
Concept #1: Break work down to get work done
Sprints
The way Scrum breaks down work iteratively is one of the key features of the framework. Scrum says that teams should define a short period of time to do work in. At the end of the designated time the team should stop to review their work, get feedback on both the work and the process, then plan out the next period of work. These periods are called sprints and Scrum suggested to keep these between 1 and 4 weeks in length. The time frame should be consistent from sprint to sprint in order to establish an organizational rhythm or cadence. Each sprint ends on time and another begins, regardless of the work that was actually accomplished. This gives the team a chance to reset and create a new plan every few weeks.
In contrast, traditional Waterfall Project Management has a project start and end date with milestones based on completed work. Projected dates are generally set for milestones, but if the work is not completed, the date is moved.
Stories
User stories in Scrum are the vehicles used to communicate objectives to the team. There are several formats for user stories, but the traditional concept taught by Scrum follows this pattern. “As a Position I need Action so that Reason”. One example of this in the software industry could be “As an admin user I need the ability to delete files so that the system does not fill up with outdated documents.” This format gives a team acceptance criteria without spelling out the specific implementation strategy. It gives the team ownership of the solution which is a key tenet of the Agile methodology. It also allows the team to tackle small amounts of work that can be completed and rolled out iteratively.
In contrast, traditional Waterfall Project Management defines scope of all aspects of the project before handing it to the team. Projects are still broken up into features for reference, but are generally not divided into smaller stories or tasks. In Waterfall, there is no need to break them up further because the project as a whole will be worked on until it is done.
Points
Points in Scrum are used as a tool to rate the amount of work each story will take to complete relative to other stories. If you have two runners at different fitness levels, it will take them different amounts of time to run a mile. Yet a mile is a mile regardless of how long it will take one or the other the run it. In the same way if you have two developers of different experience levels, they will take different amounts of time to complete a story. Yet the story is the same size regardless of who builds it and how long it takes them. In scrum, points are used for work just as miles are used for distance. This eliminates the variation between skill levels and helps create a baseline for the amount of work done in a team comprised of people with varying levels of skill. Both novices and skilled implementers may have 40 hours in their work week, but one can do twice as much work in that 40 hours as the other can. Points are what scrum uses to show the difference between the two implementers.
In contrast, Waterfall Project Management focuses on estimating work by the hours or days it will take to complete each step or milestone.
Concept #2: Toil as a team
Product Owner
In Scrum, the owner of the vision and scope is the Product Owner. This can be a full time position, or a role played by a client, product manager, or other stakeholders. The primary responsibility of this position is to define and prioritize the Product Backlog; a comprehensive collection of stories needed to complete the product. Essentially, they are responsible for creating or collecting the “What” and “Why” for the team, then translating that into small chunks of work.
In contrast, Waterfall Project Management generally has a traditional project manager filling this role. Instead of a backlog of stories they create detailed project plans.
Scrum Master
The Scrum Master is the servant leader of the team. Their role is to coach the team on the process and facilitate all Scrum Ceremonies. (These are described in the Focus on Feedback section below.) They also work with the Product Owner to make sure everything is prepared for the team. The most important role of the Scrum Master though is the less defined position of team linebacker. Their job is first and foremost to help make the team productive by identifying and clearing up time consuming roadblocks. Whether that’s a vender who is not responding, or workstation that is glitching. The Scrum Master is responsible for playing defence against the teams or projects natural entropy.
In contrast, Waterfall Project Management assumes the team will take care of any unaccounted roadblocks. Often, extra time is arbitrary introduced to the project plan upfront, to account for the inevitable distractions and unpredictable interference.
Scrum Team
In scrum, projects are completed by cross functional teams of seven people (give or take two). For software development teams, the ideal is to have the teams staffed with full stack developers who can architect, build, test, and deploy. This is not always possible however since most people tend to specialize at some point in their career. Because of this, teams should be comprised of a good balance of specializations, but each team member must understand that they are responsible for sprint commitments as a team not as an individual. This means that sometimes a developer must test and an architect must write front end code. The important thing is that the team is built around a motivated individual, that they are given the environment and support to succeed, and that they are trusted to get the job done. (Agile Principle #5)
In contrast, Waterfall Project management focuses on individual contributors rather than teams. It schedules work for people and expects each one to be responsible for their own assigned work.
Concept #3: Focus on Feedback
Planning
This is the primary ceremony of Scrum. It generally lasts several hours and is used as the kick off event at the beginning of each sprint. During planning, the team pulls stories from the product backlog and puts them on the sprint backlog, they turn the stories into tasks, and most importantly, they commit to the amount of work for the next sprint. If any stories in the product backlog are missing a story point rating, the team will go through a planning poker exercise to rate them. This event gives the team a chance to reset every few weeks and plan the next few weeks based on the most relevant data available.
In contrast, Waterfall Project Management teaches people to plan everything upfront and only adjust when things go wrong.
Standup
In Scrum, the team meets everyday for a quick 15 minute status meeting. In this meeting everyone stands to encourage a short meeting. Everyone in the team gives a quick update on what they did yesterday, what they are doing today, and any roadblocks they are dealing with. This helps facilitate communication and learning amongst the team members while also informing the Scrum Master of any impediments that they can help remove. It also serves as an early warning system for the sprint to alert the team when their commitment is at risk.
In contrast, Waterfall Project Management traditionally waits until a milestone completion date to understand the status of the project and issues that threatened the final project delivery date.
Review
The review is a critical ceremony in Scrum, comprised of a demo of working software and the opportunity for stakeholders to ask questions and give feedback. This serves two main purposes. First it gives any stakeholders a chance to see the iterative progress of a project, second it creates a forcing function for the team by setting short term delivery expectations based on sprint commitments.
In contrast, Waterfall Project Management waits until a milestone is completed before a review is held. Any feedback has the potential to derail the project plan and thus is kept to a minimum.
Retrospective
In Scrum, after the review and before sprint planning, the team is asked to assess the past sprint to identify what went well, what didn’t go well, and then to decide on one or two things that could be done in the coming sprint to speed the team up. This could be anything from a process change, to a new tool, or even an adjustment of expectations.
In contrast, Waterfall Project Management waits until the end of the project to get feedback. If the project went well, often times this is skipped. If it did not go well, there is a detailed post mortem exercise to identify and correct all issues as a broad sweeping change effort.
Visibility is a Virtue
Scrum Board
Making work visible is a key tenant of Scrum. The Scrum Board is the primary way to make that happen. The board is divided up into three vertical columns labeled as: Todo, Doing, Done. Cards or sticky notes are created for each task or story in a sprint, and then they are moved from column to column as work is completed. At the end of the sprint, the board is reset and any work not completed goes back to the Product backlog to be reassessed and committed do during the sprint planning event. This was traditionally done on a physical board or wall, today it is often done inside of a software product. Whatever the case, it is critical that the board is discussed in standup each day and that it is visible to the team and any stakeholders at all times.
In contrast, Waterfall Project Management uses gantt charts with a vertical line for the current date to show the expected progress rather than the actual state of the project.
Burndown
In Scrum, the Burndown chart is the primary information radiator for the progress in a sprint. This is created as a line chart with the total number of story points on the left and a line descending to 0 story points on the right. The horizontal axis represents the amount of working days in a sprint. As each day starts, a dot is added to the chart representing the amount of Story Points left on that day. The dots from day to day are connected with a trend line that shows how far a team is ahead or behind schedule during the sprint. This communicates to the team and all stakeholders the details around what is going on as the sprint unfolds.
In contrast, Waterfall Project Management uses gantt charts to show if a project is on track based on the original plan.
Velocity Chart
To track a teams speed from sprint to sprint, a bar chart is created that shows the number of story points completed in each iteration. This gives the team a scorecard that helps them plan future sprints and challenges them to improve their efficiency and speed.
In contrast, Waterfall Project Management uses hours or days which can only be adjusted by adding or removing people and does not account for skill levels, nor does it encourage improvements in efficiency.
For a more in-depth look at Scrum, I would encourage you to read the book “Scrum, the Art of Doing Twice the Work in Half the Time.” by Jeff Southerland.
Leave A Comment