Scrum is the fastest growing Agile framework. Yet, incredibly difficult to implement.
In my last article, I gave a brief overview of Agile. As mentioned before, Agile is a set of principles that encompasses many frameworks such as Extreme Programming, Lean, and the most popular framework, “Scrum”.
Like traditional project management, there exist processes. Each process will have an input, enablers/ controls (called tools and techniques in Waterfall), and outputs. However, processes in the form of Agile develops “working software” or a working deliverable via one or more processes.
Unlike traditional project management, Agile- and by extension Scrum- does not necessarily define the total scope nor plan everything up front. Instead, scope and planning are done iteratively or adaptively as unknowns become known. This is especially true where a new and novel product is being created (or invented) such as in the software or pharmaceutical industry.
Scrum Background and Start
Scrum originated in theory back in 1986 by two competing theorist from Japan. Hirotaka Takeuchi (now a professor at Harvard Business School) and Ikujiro Nonaka published a white paper titled “The New Product Development Game” in the Harvard Business Review describing a methodology that resembled Rugby. Thus the name Scrum later came to be.
In 1993, three westerners fined-tuned “Scrum”. They were Jeff Sutherland, John Scumniotales, and Jeff McKenna. However, Scrum did not gain real popularity until Ken Schwaber and Mike Beedle wrote and published the book titled “Agile Software Development with Scrum” in 2001.
Scrum, like most other frameworks built off the Agile principles, is meant to be lightweight and simple to understand, yet proves to be difficult to master when adopted in an organization.
Scrum was founded on “empiricism”, meaning knowledge is learned through our senses. It is not merely inherited. In other words, knowledge comes from experience ocmbined with what is already known.
There are three pillars that uphold every implementation of empirical process control:
- Transparency – every aspect of a process must be visible to the person or persons responsible for the outcome. Note- In Agile, the team is always responsible, not an individual.
- Inspection– Use frequent inspections of deliverables (or artifacts discussed later). However, inspection should not be so frequent that is gets in the way of work.
- Adaptation– If during inspection, the development team sees uncontrolled deviations or that the deliverable will not work, changes are made quickly to minimize further deviation. Combined with inspection, it creates an environment of continuous improvement through Scrum.
Inspection-and-adaptation is seen and practiced through four formal Scrum events (each discussed in more detail later).
- Sprint Planning
- Daily Scrum
- sprint Review
- Sprint Retrospective
There are three main components of Scrum that we will discuss in order. They are the Scrum team, artifacts, and events.
Key members of a Scrum Team
In Scrum, it is vital to know the key members of the project team.
In Waterfall Project Management, this would likely be the sponsor of a project. In Scrum, the sponsor is know as the product owner. The product owner ensures that the project is profitable and has a positive return on investment.
As such, the product owner prioritizes the features of a product and/or outcomes of a “sprint” (discussed later). The product owner is allowed to adjust these features or outcomes as well as their priority when needed in order to adjust rapidly to market conditions etc. This dynamic allows the product owner to focus on the “what” of the project, not the “how” or method it will be completed.
This list of “whats” is called a “product backlog” which will be discussed further later. The product owner helps create and manage this list by:
- Clearly, without ambiguity, defining the items on the product backlog
- Prioritizing features or outcomes
- Adjusting their priority (order of completion) as needed and when needed
- Optimizing the product value of work being performed by the team
- Making sure the product backlog is visible, transparent, and clear to the team through showing what the team will work on next
When a deliverable is completed in a certain sprint, the product owner is the one who will accept or reject the deliverable. (Similar to “Validate Scope” process in Waterfall.) Unlike waterfall, a product owner is one person- it cannot be a group. This person has complete authority over the product.
Similar to all other types of project management, Scrum has a team. There are some similarities, but many differences as well. This team is the group that will execute the work in time-boxed “sprints” that will be discussed later.
In Scrum, team members are all called “developers”. This arises out of the fact that Scrum was originally built for the software industry.
In Scrum, teams are self-organizing. This means that your team will naturally bond into a group and should remain on the same team regardless of project. The team will develop their own set of operating guidelines under the leadership of a Scrum Master.
Development teams are cross-functional. In other words, each team member can do every task in a backlog. There are no sub-teams as all members are cross-functional.
As mentioned earlier, not one individual is accountable for an action or result. Rather in Scrum, the entire team is held accountable as whole. The teams responsibilities are the following:
- Delivery of a product increment
- Quality of a product increment
- Self-managing their own work
- Estimating the product backlog items by estimating the effort for each item
Attaining the right sized team for optimization is key. The team must be small enough for agility but large enough to complete significant work within each sprint. The amount of work in a sprint is called “velocity”.
The team should be between three to nine developers. This team size is in addition to (does not count) the Scrum Master and the Product Owner. The thinking is that any development team less than three decreases interaction and results in smaller productivity. In contrast, teams greater than nine requires too much coordination to be self-led, and generates avoidable complexity.
The Scrum Master is the project manager per se. But because there is technically no hierarchy in a Scrum team, he or she is not a manager. More like a captain of a sports team.
This expert is a servant-leader that is primarily responsible for ensuring Scrum practices are being followed and is charged with removing impediments so the team can focus on the work at hand. The Scrum Master facilitates and leads events of Scrum and ensures consensus. The Scrum Master is also responsible for the following:
- Ensures engineering practices are being followed
- Removes impediments (conflicts or roadblocks to success) are addressed and removed
- Coaches the development team in self-organization and cross-functionality
- Advises the Product Owner on how to arrange the product backlog to maximize value. Provides counsel and advice so the client sees deliverables continuously in a logical flow for the overall product.
So far, we have discussed the scrum team. Now we will discuss scrum artifacts. These are a set of documents or charts that will facilitate organization of the overall product and what has to be completed. These artifacts encourage transparency of the product. every member should know every aspect regardless of role.
Product Backlog (PBL)
The product backlog is an ordered list of everything that might be needed in the product. This list is the responsibility of the product owner to include its content, availability, and order of the list. The product backlog specifies the “what” and “how” of a feature from a customer-centric perspective. These items are written in a “story” form in a format similar to “As a (type of user), I want (goal of deliverable) so that (reason or why).” For example, “As an account manager, I want to search the database of existing leads, so that I can close deals“.
The product backlog should have a product wide “definition-of-done” (discussed later) to prevent technical deficit. The PBL may also contain acceptance criteria needed.
Effort to complete the work is estimated by the development team with input from the product owner. The list of all the items on the PBL should include the features, requirements, enhancements, and fixes that constitute changes to be made to the overall product in future releases (scope in Waterfall). Effort may be expressed in man hours or similar. Story points, this is a more qualitative measure of effort. Yes- it can be confusing. For more information, click here!
Items at the top of the PBL are more detailed than the ones of lower priority at the bottom of the PBL. This is an example of rolling wave planning taught in the PMBOK 6th ed. Keep in mind that the PBL is a constantly evolving artifact of Scrum.
The PBL is visible to all stakeholders on the project. As it evolves, it can change in priority or needs depending on changing market conditions, budget etc. Similar to a Work Breakdown Structure in Waterfall, estimates can be achieved to forecast time of remaining work and possibly budget.
PBL refinement (aka “grooming”) is the activity of creating and refining the PBL, estimating activities, and prioritizing them at any given point.
Sprint Backlog (SBL)
Similar, but not to be confused with the product backlog (PBL), the sprint backlog (SBL) is a set of the PBL items selected for a current sprint. This backlog was a forecast of the development team concerning what functionality can be achieved in the sprint at hand.
During the spring planning meeting, the SBL list is derived by selecting stories (features) from the top of the PBL until the development team feels it has enough work to fill a sprint. This is based on the “velocity” of the team. “Velocity is a measure of the amount of work a Team can tackle during a single Sprint and is the key metric in Scrum. Velocity is calculated at the end of the Sprint by totaling the Points for all fully completed User Stories.” (Scrum Inc. 2018)
Whereas the product owner is the only person that can modify the PBL, the SBL (during a sprint) is only modified by the development team. As more information is learned through development, the SBL may need to be modified based on current capabilities and velocity of the development team.
- Specifies “how” to achieve the PBL’s “what”
- Each task requires one day or less of work for each team member. If it is more than one days work, it should be further broken down.
- Enables easy follow-ups on each task during the daily scrum
- Remaining effort is re-estimated daily, typically in work hours
- Sprint tasks are owned collectively by the team, regardless of who is working on a task
- The cumulative completion of each tasks ultimately results in achieving the sprint goal for that sprint
In essence, the SBL is a highly visible real-time picture of the work the development task plans to accomplish during the sprint. Is shows the total work remaining at any given point in the spring.
Think of the product backlog as the work package in Waterfall- the sprint backlog would be the task list
Potentially Shippable Increments (PSI) also known as “Increments”
The potentially shippable increments (PSI) is the sum total of all the PBL items completed during a sprint and the previous sprints. SBL items rill into a sprint goal, the sprint goal creates a PBL item which roll into a PSI.
At the end of a spring, the increment must be done according the the Scrum teams “Definition of Done” criteria (discussed later). The increment must be in a usable condition. This is regardless of whether or not the the product owner decides to release the increment to the end user.
With the above key figures and artifacts in Scrum addressed, we now put these into action. Scrum has defined events that center around “sprints”. First a sprint is planned, then executed, and then reviewed. First we will discuss what the actual sprint is and then move to planning, daily scrums, and post sprint activities.
Sprints are time-boxed iterations, usually one more or less (most commonly two weeks) where a deliverable (working software) is produced from the backlog (discussed later under “Artifacts”). After one sprint ends, another one begins. Sprints always begin with sprint planning which will also be discussed in more detail later.
Sprint lengths are internally pre-determined and should remain the same throughout the project. In other words, only pull enough work into a sprint in order to remain in that pre-determined time-frame; no more and no less. If an adjustment is made to sprint lengths, then the change should apply to all future sprints as well.
During a sprint, no changes are typically accepted. Why is it discouraged? Even though it is part of an Agile framework, sprints are time boxed and the scope of the sprint is defined as well as resources. However, when a sprint does change, scope should be clarified or renegotiated by the product owner and development team; especially as unknowns become known.
Although uncommon, a sprint can be cancelled by the product owner. If this happens, finished work should be reviewed to see if can be released for added value to the organization or client.
Definition of Done (DOD) in a Sprint
In order for a sprint to be “complete”, it must meet the “Definition of Done” or “DoD”. This occurs when all featured included in the sprint are implemented. The following further defines this concept:
- Code meets general coding standards based on internal and external standards
- Functional tests are performed by the team- rework is completed if any failure is noticed
- Code is reviewed in a “pair-programming” method as two sets of eyes are better than one
- Code is “green” and works properly
- Acceptance test must be “green” as well
- Integration test of the affected area passes. Does it mesh well with other software?
Now that we discussed the actual sprint, we are going to back up to sprint planning. This is performed prior to the sprint taking place.
Sprint planning is where the work to be performed in a sprint will be planned collaboratively. In sprint planning:
- Team agrees on a sprint goal by defining what the upcoming sprint is expected to achieve.
- The development team provides effort estimate for the sprint. For example, 50 man days of work for this sprint equals enough resources to complete the work in the time-frame allotted for a sprint. (See “poker” technique).
- Sprint planning has time constraints. Typically, a one month sprint will have eight hours of sprint planning. So a two-week sprint should have four hours of planning.
So what gets answered during sprint planning? Here are few examples:
- What can be delivered in the next increment?
- How many products from the backlog can be completed in the predetermined sprint time-box? This is called the “sprint goal” and is decided by 100% consensus of the team.
- How will the work effort be achieved? This is presented to the product owner and he/ she will clarify and may request trade-offs.
- The team asks itself, “How will we self-organize and accomplish this goal?”. The team then briefs the scrum master and product owner.
Daily during a sprint, the scrum master will hold a daily “stand-up” meeting called the daily scrum to begin the workday with the development team. This meeting should never be more than 15 minutes in duration. This meeting is to discuss impediments, synchronization efforts, etc. Three main questions are answered in this 15 minute meeting daily:
- Each team member quickly briefs answers “what did I do yesterday to help the development team achieve the sprint goal?” Each team member will take a task and speak about it.
- “What will I do today?”
- What impediments do I see getting in the way of the development team meeting the sprint goal?
Example: “I created the table for the relational database in order to import existing clients into the new database. I am having an issue with department XYZ providing a data file of existing clients.” Scrum Master replies, “I will get with John in department XYZ to find out when exactly this data file will be sent.”
The benefits of a daily scrum is that communication is improved. All meetings are face to face and thus provides benefits not achievable via remote. Additionally, daily scrums remove the need for other meetings which can disrupt the flow. It also provides the scrum master an idea of the impediments faced by the team so he or she can eliminate these burdens.
Daily scrums also highlight and promote rapid decision making for immediate absolution. While doing so, this process improves the development teams knowledge and acts as a key “inspect-and adapt” meeting.
Activities After a Sprint
After a sprint, there are two key activities; the “sprint review” and the “sprint retrospective”. The key difference between the two is that a sprint review has the product owner (aka the client or sponsor) in attendance to ensure the deliverable meets the requirements and the sprint retrospective does not. The sprint retrospective is to determine what went well, what should be changed on follow-on sprints etc.
Held after each sprint, the team and the product owner get together and inspect the main deliverable(s) of that sprint. It determines one key question, “Did the team achieve the sprint goal?”.
The scrum team, perhaps through demonstration, shows the product owner what was accomplished, what was not, and why. It is meant to be an informal meeting- not a status meeting. The purpose of this activity is another opportunity to inspect-and-adapt the deliverable.
For a one month spring, the review is limited to a four hour time-box. So for a two week spring, this review will be capped at no more than two hours.
Similar in nature to a sprint review, the retrospective is held without key stakeholders. Instead the team gets together and discusses ways to do the next sprint more efficiently and effectively. Why? Because there is always room to get better- no matter how awesome the team is performing.
This meeting will always happen after the sprint review and prior to the next sprint planning session. It is time boxed to three hours per one month sprint and adjusted accordingly to your teams predetermined sprint length.
This is another inspect-and-adapt meeting to discuss:
- What went right, what went wrong, and what can be improved upon
- Is Scrum working?
- Were items able to be completed in the sprint time allotted?
- What can be done to increase quality?
- How will improvements in the next sprint be implemented?
It is very important that this meeting does not turn into a blame or finger-pointing session! Scrum master must prevent this from happening.
Scrum is not right for every project. In fact, Scrum (and all Agile frameworks) are really to be used where new and novel products are being created especially in industries like pharmaceutical development or software development.
Below is a chart that encompasses all of Scrum to show how simple it should be, but how hard it is to correctly implement into an organization. The below image is from Scrum.org which is one of two main bodies of Scrum governance.
Nathan J. Kerr, MS, PMP is the co-owner and founder of PMCertDC – Washington D.C.’s metro area premier project management boot camp provider. With our primary location in Tysons, Virginia, we hold classes throughout the Washington D.C. metro area and anywhere online.
We are a proud Service-Disabled Veteran-Owned Small Business with a huge impact on the project management world. Visit us at https://pmcertdc.com
Read why PMCertDC is awesome here!