PEARL XIV : An Inquiry on Release/Hardening sprint in Scrum

PEARL XIV : An Inquiry on Release/Hardening sprint in Scrum

There is a deep divide between people who recognize that spending some time on hardening is needed for many environments, and people who are adamant that allocating some time for hardening is a sign that you are doing some things – or everything – wrong

A Hardening/release sprint, often part of a project using agile management methodologies, incorporates activities, sometimes not related to creating product features, that the development team can’t realistically complete within development sprints. To accommodate prerelease activities and help ensure that the release goes well, scrum teams often schedule a release sprint as the final sprint prior to releasing product to customers.

There are two components of the Production Release practice: 1) Release Preparation, and 2) Deployment. Release preparation establishes a release baseline and produces all the necessary supporting material necessary to deploy (and back out, if necessary) the release.

Deployment involves the act of delivering the release into the production environment, verifying that the integration of the release package into the existing environment was successful, and notifying all relevant stakeholders that the features of the release are available for use.

The Hardening release sprint should contain anything you need to do to move the working product to production. Sprint backlog items in a release sprint may include

  • Creating user documentation for the most recent version of the product
  • Performance testing, load testing, security testing, and any other checks to ensure the working software — or other product — will perform acceptably in production
  • Integrating the product with enterprise-wide systems, where testing may take days or weeks
  • Completing organizational or regulatory procedures that are mandatory prior to release
  • Preparing release notes — final notes about changes to the product

If your product is software, backlog items for the Hardening release sprint may also include

  • Preparing the deployment package, enabling all the code for the product features to move to production at one time
  • Deploying your code to the production environment

In a hardening sprint, the team stops focusing on delivering new features or architecture, and instead spends their time on stabilizing the system and getting it ready to be released.

For some people, hardening sprints are for completing testing and fixing work that couldn’t be done – or didn’t get done – earlier. This might include UAT or other final acceptance testing if this is built into a contract or governance model.

Mike Cohn recognizes that teams may need a “ hardening/release sprint” at the end of each release cycle, because the team’s definition of “done” may not be enough – that a “potentially shippable product”and a system that is actually “shippable” or ready for production aren’t the same thing. He suggests that after every 3-5 feature iterations, the team may want to schedule a release sprint to do work like expensive manual system and integration testing and extra reviews, whatever is needed to make sure that what they think is done, is actually done.

Anand Viswanath, in “The end of regression, stabilisation, hardening or release sprints”, describes a common approach where teams schedule 1 or 2 stabilization sprints every 4-6 iterations to do regression testing and system testing in a staging environment, and then fix whatever bugs are found. As he points out, it’s hard to predict how much testing might be required and long it will take to fix whatever problems are found, so the idea is to time box this work and then triage the results.

Because this can be an expensive and risky and stressful way to work, Vishwanath recommends following Continuous Delivery to build an automated test pipeline through to staging in order to catch as many problems as early as possible. This is a good idea, but most large projects, especially projects starting from a legacy code base, will still probably need some kind of hardening or integration testing phase at regular points regardless of what kind of continuous testing they are doing.

Some testing, like interoperability testing with other systems and operational testing, can’t be done effectively until later, when there is enough of a working system to do end-to-end testing, and some of this testing can only be done in staging , or in production. For some systems, load testing and stress testing and soak testing also needs to be left to later, because these teams don’t have access to a  right high end test system to run high load scenarios before they get to production.

Is Hardening a sign that you aren’t doing things right?

Not everyone thinks that scheduling a hardening sprint for testing and fixing like this is a good idea:

“[a hardening sprint] might take the cake for stupid things invented that has lead to institutionalized delusion and ‘Agile’ dysfunction.” Janelle Klein, Who Came up with the “Hardening Sprint”?

For many people, a hardening sprint or release sprint is a bad “process smell”: a sign that the team isn’t working properly or thinking clearly:

“The problem with “hardening sprints” is that you are lying. You make believe your imaginary burndown during the initial sprints shows that you are approaching Done. But it’s a lie–you aren’t getting any closer to being ready for Production until you begin your Test phase. You wrote a pile of code that you didn’t test adequately. You don’t know how good it is, you don’t know how much work you have left to do, and you don’t know how much longer it will take, until you are deep into your Test phase.” Richard Kasperowski, Hardening sprints? Sorry, you’re not Agile

Ron Jeffries says that a hardening sprint for testing and fixing is a clear anti-pattern. Many Agilists agree: if you need a separate sprint to fix bugs, then you’re doing something wrong. But that doesn’t mean that you won’t need extra time to fix things before the system goes live – knowing that it is wrong doesn’t make the bugs go away, you still have to fix them. As the same discussion thread points out, there is a risk that your “definition of done” could fall short of what is actually needed by the customer, so you should plan for 1 or more hardening sprints before release, to double-check and stabilize things, just in case.

In these cases, the need for hardening sprints is a sign of a team’s immaturity (from a post by Paul Beavers):

  1. A beginning agile team will prefer to schedule 6 hardening iterations after a 12 iteration development plan. This is “agile” to the hard core “waterfall guy”.
  2. As time goes by, the team will mature a bit and you will see the seasoned agile team will shrink the number of required hardening iterations at the end, just because they understand they need to “fix” the high severity bugs as they go and QA understands they need to test closer and better early up in the release cycle.
  3. Further down the road the team will notice that by adding a hardening iteration in the middle of the development cycle (and flushing out even lesser priority bugs earlier on in the process), it will help them to maintain cadence later on.
  4. The final step of maturity is there when the team starts understanding “hardening is not required any more”, because they made fixing bugs part of their daily routines.

Hardening is whatever you need to do to Make the System Ready for Production

Another way of looking at hardening, is that this is when you stop thinking about features and focus all of your time on the detailed steps of deploying, installing and configuring the system and making sure that everything is working from end-to-end. In a hardening sprint, your most important customers are operations and support, the people who are going to make sure that the system is running, rather than the end users.

For some teams, this kind of hardening can come as an ugly and expensive surprise, after they understand that what they need to do is to take a working functional prototype and make it ready for the real world:

“All those things that got skipped in the first phase – error handling, monitoring, administration – need to get put into the product.” Catherine Powell, The “Hardening Myth”

But a hardening sprint can also be when when you take care of what operations calls hardening: reviewing and preparing the production environment and securing the run-time, tightening up access to production data, double-checking system and application configs, making sure that auditing is enabled properly, wiring the system in to operations monitoring and metrics collection, checking system dependencies like platform software versions and patch levels (and making sure that all of the systems are consistent, that there aren’t any snowflakes), completing final security reviews and other review and release gates, and making sure that the people installing and running the software have the correct instructions.This is also when you need to prepare your roll-back plan or recovery plan if something bad happens with the release, and test your roll-back and recovery steps. Walk through and rehearse the release process and checklists, and make sure that everyone is prepared to roll out patches quickly after the release is done.

Jail Free Card

Agilists have also heard of hardening sprints being used as a sort of “get out of jail free card” within Scrum teams. The conversations are usually along the following lines:

We don’t have enough time to test that component properly, so we’ll do it in hardening

We don’t have time to fix all of the cosmetic bugs we produced in this sprint, so we’ll do it in hardening
Let’s defer customer support training entirely to hardening
The design is still too volatile to document. We’ll wait until it stabilizes and document it in hardening

What is happening here has to be noted ? Hardening can undermine the broad definition of done that is so incredibly important to Scrum’s quality and delivery dynamics. But if it is so bad, why do it at all? That is why there are some of the contexts where hardening might not only be a good idea, but almost required.

Hardening is something that you have to do

Some people see an obvious need for hardening sprints. For example, Dean Leffingwell includes hardening sprints in his “Scaled Agile Framework”, because there is some work that can only really be done in a final hardening phase:

  • Final exploratory and field testing
  • Checklist validation against release, QA and standards governance
  • Release signoffs if you need them
  • Ops documentation
  • Deployment package
  • Communicate release to everyone (hard to do in big companies)
  • Traceability etc for high assurance and regulatory compliance

Leffingwell makes it clear that hardening shouldn’t include system integration, fixing high priority bugs, automating test scripts, user documentation, regression testing and code cleanup. There is other work that should be done earlier – but in the first year or so, will probably need to be done in a late hardening phase:

  • Cross-component integration, integration with third-party/customer
  • Integrated system-level testing
  • Final QA sign-offs
  • User doc finalization
  • Localization

Dan Rawsthorne explains that teams need at least one release sprint at first to get ready for release to production, because until you’ve actually done it, you don’t really know what you need to do. Release sprints include tasks like:

  • Exploratory testing to double check that key features are working properly
  • Stress testing/load testing/performance testing – testing that is expensive to setup and do
  • Interoperability testing with other production systems
  • Fix whatever comes out of this testing
  • Review and finish off any documentation
  • Train support and sales and customers on new features
  • Help with press releases and other marketing material

The Software Project Manager’s Bridge to Agility anticipates that teams will need at least a short hardening iteration before the system is ready for release, even if they frontload as much testing as possible. A release iteration is not a test-fix phase – it’s when you prepare for the release: capturing screenshots for marketing materials, final tests, small tweaks, finish documentation for whoever needs it, training. The authors suggest however that if some developers have any time left over in the release iteration, they can do some refactoring and other cleanup – which Agilists think is bad advice, given that at this point you don’t want to be introducing any new variables or risks.

Disciplined Agile Delivery, a method that was developed by Scott Ambler at IBM to scale Agile practices to large organizations and large projects, includes a Transition Phase before each release to take care of:

  • Transition planning and coordination
  • End-of-lifecycle testing and fixing
  • Testing and rehearsing deployment
  • Data setup and migration
  • Pilots and beta testing (short UAT if necessary)
  • Reviewing and finalizing documentation
  • Preparing operations and support
  • Stakeholder training

This kind of transition can take almost no time, or it can take several weeks, depending on the situation.

Hardening – taking some time to make sure that the system is really ready to be released – can’t be avoided. The longer your release cycles, the further away development is from day-to-day production, the more hardening you need. Even if you’ve been doing disciplined testing and reviews in stream, you’re going to find some problems at the end. Even if you planned ahead for transition, you’re going to run into operational details that you didn’t know about or didn’t understand until the end.

When agilists first launched a platform from start up, they had to do hardening and stabilization work before going live to get the system ready, and some more work afterwards to deal with operational issues and requirements that they weren’t prepared for. They included time at the end of subsequent releases for extra testing, deployment and roll back planning, and release coordination.

But as they shortened their release cycle, releasing less but more often, and as they built more fail-safes into the system and as they learned more about what they needed to do in ops, and as they invested more in simplifying and automating deployment and everything else that they could, they found that they didn’t need time any outside of  regular iterations for hardening. They a’re still doing hardening – but now this is part of the day-to-day job of building and releasing software.

But there are a whole lot of contexts where hardening can be incredibly useful. Here are a few of these, just to set you up for healthier applications:
1. Distributed and At-Scale Agile: It is quite easy to say that a team should “integrate” their software fully within each sprint. But what if you have 20-50 teams working on the same project and the teams are geographically distributed?
Sure, you want to try to integrate as much as possible across the teams, but clearly you are not going to do it all. It just does not meet reasonable ROI on a sprint-by-sprint basis.
In these cases, having a hardening sprint that is focused toward full Integration, regression, and system testing might be a prudent trade-off.

.2. Customer Receptivity: Something that gets lost in the “potentially shippable product increment” goal that is such a strong part of Scrum is – what if your customer simply cannot tolerate or accept a release every 1-2-3 weeks? What do you do then? Many domains and customers simply cannot.
The game is then to accumulate partial release contents over the course of several-to-many sprints. But then there is the need to re-qualify all of that code when you are ready
to do a real (not potential) release.
3. Test Automation Coverage: Having high degrees of test automation, and automation in general, is one of the ways that agile teams can truly go fast. It provides a wonderful development safety net and gets feedback to the team quickly. But what if you do not have it? What if you are currently stuck with thousands of manual, albeit valuable, test cases to run? Clearly if you run all of them within each sprint you would derail the focus. But running risk-based regression and functional testing is risky since you are deferring levels of coverage. A hardening sprint is a solid way to handle this technical test debt  before releasing.
4. Skewed Sprint Consolidation: In many agile contexts, some work is done a “sprint ahead” of other activities. For example, UX design is often completed by a design Scrum
team and then “handed off” to a front-end implementation team for coding in a follow-on sprint. This sort of staging often happens with research (story spikes), design, architecture, and other up-front activities in projects. The hardening sprint is a place to check that all of these skewed activities have come together into a cohesive package from a customer perspective. It certainly should not be the first or only time, but it can serve as a design convergence point.
5. Defect Rework: At the end of the day, bugs are discovered pre-release whether you are implementing Waterfall or Agile methods. If you are doing Agile well, then you are finding fewer and the rework cycle time is much shorter. But, inevitably, some cleanup of bugs pre-release is fairly normal. Reserving time in your hardening sprint gives you some time for final defect cleanup before making the release.
6. Deployment Readiness and Training: There is a “whole lot” of work required to get a release out the door in many organizational contexts and business domains.  Agilists think one of the things that “potentially shippable product increment” does is to trivialize this level of pre-release preparation. While thier definition of hardening sprints tends to be more testingand defect-repair focused, it is an interval that allows time to prepare software for, err, release! Dan Rawsthorne has written an article on the Agile Atlas site entitled Out the
Door: the Release Sprint, which is perhaps another name for a hardening sprint. Dan focuses the sprint on this area though –finishing all of the details surrounding actually
releasing a supportable product.

Regulations, Governance, and the Art of Trivialized Agile Testing: Finally, another focus for a hardening sprint is making all of the steps and creating all of the obliged artifacts that meet your internal and external regulations for the product. Consider it a “governance acceptance test” checklist where various requirements are exercised and confirmed. Quite often this includes a full regression test that provides traceability between the project requirements (User Stories) and the tests that covered that functionality.
In many domains, financial and healthcare for instance, proof of completeness and following your predefined processes are required steps pre-release

These sorts of sprints are considered a Scrum-butt or Scrum anti-pattern by many of the leading Scrum authorities (CST’sand CSC’s)

PEARL XV : Beyond Scrum : A Scalable Agile Framework with Continuous Integration

PEARL XV : Beyond Scrum :  A Scalable Agile Framework with Continuous Integration using Test Automation and Build for Large Distributed Agile Projects.

scalable agile process

Scrum is the most popular Agile technique, but it doesn’t scale well. And while Scrum improves the effectiveness of individual teams, productivity gains fall off sharply on large projects with many teams.

Yet Agile methods have been used in very large commercial and open source projects to increase productivity, quality and release frequency. Here are a couple of examples:

  • Facebook incorporates code from 600 developers while delivering two releases per day.
  • The Google Android project utilizes thousands of contributors spread across the world.
  • Flickr reached a level of 10 deployments per day.

Can we learn from these companies and projects? What types of techniques and tools did they use to achieve those results?

This section will cover the problems with Scrum, changes in approach to help scalability and methods for supporting distributed teams and continuous delivery.

Problems With Scrum
Scrum techniques have been very successful in improving the effectiveness of individual development teams, employing concepts like self-directed co-located teams, time-boxed sprints, and regular customer feedback from working software. Yet many organizations have run into obstacles when trying to apply Scrum techniques to large projects. For example, no effective techniques have evolved to coordinate the work of multiple Scrum teams and manage dependencies among them. The “Scrum of Scrums” approach of holding meetings with representatives of every team becomes increasingly time-consuming and unwieldy as the number of teams multiply.

In part, this is because some of the assumptions underlying Scrum are too restrictive for large organizations, or clash with business requirements. Many groups refuse to be limited to co-located teams because they are already distributed, they want to take advantage of the global market for development talent, or simply because many of their employees work from home several days a week.

Many groups need to share key personnel such as architects, UI designers, and database specialists across many projects, and cannot assign them to a single team. Other companies need to fix bugs and release new functionality more frequently than the 2-8 week cycles typical of Scrum teams. This is particularly true of those providing web- and cloud-based applications, where customers expect a constant flow of enhancements.

This is not to say that Scrum practices have no place in a large development environment. But it is now clear that many organizations need to go “Beyond Scrum” and find new practices to manage distributed contributors and large, complex projects.

Changes in Approach That Help Scalability
The large commercial and open source projects that have successfully scaled Agile typically depart from conventional Scrum practices in several areas.

No Scrum meetings: Sprint planning meetings, retrospectives and Scrum-of-Scrum meetings are time-consuming, usually require that everyone be in one room, and usually don’t do a very good job of coordinating across teams. That’s why large-scale projects find ways to use online collaboration and planning tools to coordinate work within and across teams, with fewer meetings and conference calls.

“Pull,” “continuous flow,” and “publish what’s ready”: Although Scrum practices are far more agile than the waterfall methods they replaced, they still impose a degree of inflexibility. Once a sprint plan is complete, the features to be delivered are fixed, and so is the time frame to deliver them (usually 2-8 weeks).

Scalable projects typically use pull and continuous flow techniques (especially Kanban), so developers are always working on the highest priority tasks, and new functionality can be released as soon as it is ready.

Code review workflows (long used by open source projects) can be used to select contributions from hundreds of contributors and publish what’s ready. By helping organizations scale to more contributors and release more frequently, code review workflows can become a key building block of Scalable Agile.

Diverse contributors: Classic Scrum practices are designed for co-located teams of 8-10 members. But, in reality, large projects need to incorporate work from individual contributors, shared resources (e.g., architects and DBAs), outsourcing companies, and business partners as well as teams. Collaboration tools and code review workflows are central to meshing the work of these diverse contributors.

A Scalable Agile Process Framework
The question, then, is how can we apply the new approaches as a coherent whole?

Instead of each Scrum team having its own backlog, product management (or product owners) maintain a single project-wide backlog, with tasks sorted in priority order.

At any time, contributors can pull tasks from the top of the backlog into their own “Current Work” list. Ideally they will pull the highest-priority task, but if they do not have the necessary skills or resources they can move down the stack to find another high-priority assignment.

This process ensures that the highest-priority tasks are addressed first. If an urgent bug fix or a key customer feature request is placed at the top of the backlog it will receive immediate attention, instead of waiting for the next sprint.

Contributors can be individuals, teams, departments, or even entire organizations like an outsourcing firm or a business partner. There is no expectation or requirement that the tasks be done by Scrum teams of 8-10 members. This allows organizations to call on the talents of all kinds of individuals and companies, and in fact conforms to the reality of most large projects today.

Tasks are then managed using Kanban or lean principles. Typically this means that each person is working on one task at a time (i.e., the team has a work-in-process limit of one task for each person on the team).

Kanban principles ensure that once tasks are started they are completed as quickly as possible, which means that they can be released sooner, and also that other tasks which depend on the first task can be started sooner.

When tasks are completed, the contributor pulls in on-demand resources to build and test a release with the new code. This provides immediate feedback to the contributors, and allows them to catch and fix bugs right away. It also makes features available faster, because there is no wait for centralized build and test systems.

Finally, once new code submissions have been tested successfully, they can be pulled through a merge process into a staging area or into a final build. This means that a new version of the software can be assembled and released at any time, with whatever bug fixes and enhancements are available at that moment.

What Does This Accomplish?
How exactly does this Scalable Agile process framework address the shortcomings of Scrum and provide more scalable, responsive development efforts? Here are a few of the advantages:

  • There can be many types of contributors, including (but not limited to) conventional Scrum teams.
  • There is no need to spend time estimating tasks precisely, doing detailed sprint planning, or having long meetings to coordinate assignments across teams. As long as the backlog is maintained in priority order the highest-priority tasks will be addressed first.
  • Once tasks are started they are completed in the least possible time, meaning they can be released faster and dependent tasks can be started sooner.
  • Software quality is better, because test feedback is available as soon as a task is complete. Bugs can be fixed when it is clear what changes caused the problem, and when the code is fresh in the mind of the developer. Also, quality assurance does not become a bottleneck, a situation which often leads organizations to cut corners on testing (leading to yet more quality problems).
  • New versions of the application can be assembled and released at any time according to business demand. With sufficient automation this can be daily or even several times a day.

Scrum is the most popular Agile techniques, but it doesn’t scale well. And while Scrum improves the effectiveness of individual teams, productivity gains fall off sharply on large projects with many teams.

In the earlier section, methods on how to apply agile techniques to distributed teams and large projects was dealt. In the following section,  Tools and techniques for managing distributed teams will be addressed.

Some of the processes and tools needed to manage the Scalable Agile process framework are addressed in the following paragraphs.

The first of these “building blocks” is support for distributed teams. Large development organizations are almost always distributed because they have (1) business units and business partners in multiple locations, (2) “outsourcing” groups in different countries, (3) decided to take advantage of the global market for development talent, (4) remote employees who work from home.

So how can organizations support distributed teams well enough to reduce the need for face-to-face meetings?

Online Agile Planning
Online tools can replace paper-and-pencil planning exercises and physical whiteboards. This allows team members worldwide to create and maintain an overall project backlog, pull tasks to individual teams and contributors, move tasks through the steps in a Kanban process, and view tasks ready to be pulled into a release.

The  an online Agile planning tool is used for managing a central backlog and pulling tasks into “current” task buckets for individual teams, and an online card wall that can replace the physical variety.

online planning tools
Online planning tools can replace paper plans and physical white boards.

Online Collaboration

Development team members can collaborate most easily when they are in the same room, but online tools can provide a close approximation. Such tools include online standup reports, wikis, chat and IM products, and video and teleconferencing systems.

Another type of online tool, an activity stream gives developers real-time visibility into the activities of other team members—activities like code commits, new tickets, comments added to tickets, code reviews and posts on wikis.

activity stream

An activity stream shows commits, comments, and other events.

Global Code Management

Global collaboration can be undermined if developers need to share large repositories and large files over long distances and performance is slow.

Some of the technologies that Tool vendor Perforce uses, like proxies and replication, ensure that files are available immediately in remote locations . These solutions ensure that data is available where needed without artificial boundaries that impede sharing and collaboration.

Perforce technologies ensure that distributed team members don’t have to wait to get large repositories and files.

Decentralized Code Management
Developers often want highly decentralized code management so they can create their own local test branches and work independent of centralized corporate resources.

Development managers, however, want to maintain control over and visibility into activities at remote locations.

Git Fusion from Perforce answers both needs. Developers can quickly clone their own repositories and work in private Git repositories on their local systems, with easy code sharing between teams and products.

select directories

Release managers can make selected directories visible to Git users.

Release managers can model an entire product development effort with Perforce streams and branches, apply access controls, and control how much history and which files are cloned into new Git repositories . As changes are accepted, the enterprise release model guides changes to the right places: older releases, customizations, and parallel development efforts.

When developers commit code to the Perforce repository, the Perforce shared versioning service makes the changes visible to everyone and maintains a strong system of record about the source and nature of all changes.

The earlier paragraphs described the challenges of scaling large and distributed Agile teams, and investigated the tools and strategies that resolve them. Once the problem of scaling Agile development has been addressed, however, pressure is then applied next to the people and processes that are tasked with delivering or deploying the resulting product. Agile workflow is only successful once efficiency is attained in all stages of the workflow. This paragraph will cover the second building block of Scalable Agile: Continuous Delivery.


ScrumBan is a relatively easy first step for Scrum teams that want to move in the direction of Continuous Delivery.

Teams using ScrumBan work within a time-boxed sprint. But unlike conventional Scrum practices, a work-in-process limit is adopted, so team members are focused on finishing one task at a time. At a certain point in the sprint a “triage” process identifies which tasks can be completed within the time box, and drops the others from the sprint plan. At that point there is a “feature freeze,” and the remainder of the sprint is devoted to completing the tasks specified by the triage process.


ScrumBan represents a step toward Continuous Delivery because it emphasizes completing a small number of tasks as quickly as possible. Development teams avoid the pitfalls involved in pulling out all the stops to deliver the entire sprint plan, regardless of the cost in terms of quality and delays.

On-Demand Merge and Test by Contributor
The conventional software release process creates a huge bottleneck at the test phase. All teams send their contributions to a central QA team, which creates and tests a “release candidate.”

In traditional release processes, the QA lab becomes a serious bottleneck.

In theory this workflow makes very efficient use of the QA team and test systems, however:

  • It takes a long time to run all of the tests.
  • It is hard to debug and troubleshoot many code changes at once, especially if they may be interacting with each other.
  • Errors uncovered during the integration phase may require costly rework by several contributors.
  • The test lab becomes a huge bottleneck near the end of each sprint, causing stress and leading to sloppy testing practices.
  • Releases are delayed until the entire release candidate has been completely tested and debugged.

But what if each team can build and test based on just its own contributions?

There can be a different approach to testing. In this scenario each team and contributor has access to test resources. QA team members act as advisors and facilitators rather than being charged with managing all of the testing themselves. When a development team finishes a set of changes, the team then pulls a copy of the production version onto the test system. Changes can then be merged into this private production version, built and tested locally.
Each team pulls a product version, merges its changes, and performs its own tests.

team pulls

If testing uncovers problems, these can be solved right away by development, without worrying about interactions with changes from other teams. Multiple teams and contributors can now test and debug contributions independently, and submit them to the central staging area when ready
Teams submit tested contributions when they are ready; releases can be assembled at any time.

The advantages of this approach include:

  • QA is no longer a bottleneck—teams test independently, when they are ready.
  • It is easier to debug and troubleshoot problems, because each group is observing only its own changes to a previously tested production version.
  • Releases can be assembled at any time, constructed from whatever contributions have been tested and submitted.

These capabilities are not easy or cheap to implement. They require a considerable investment in automated build and test environments, which for distributed teams must be provided in the cloud. They also require that code merge and management be a fast and easy part of any developer’s daily work. A simple and easy-to-automate merge framework like Perforce Streams  provides merge notifications, merge pathway guidance, and intuitive tools.

In a complicated project consisting of several components, Perforce’s visibility over any part of the project also helps development teams share and reuse code. These teams can quickly adapt to a changing project structure, even if they are working in distributed repositories via Git Fusion. A merge in this environment would never require a complicated action that spans several independent repositories.

These capabilities are an indispensable aspect of Scalable Agile, because they allow very large numbers of teams to contribute to a project without overwhelming build and test resources.

Code Review Workflow
Another major challenge for Continuous Delivery is how to merge a growing number of contributions into production releases. How can you organize the flow of contributions from many sources? How can you decide when to assemble the next release? How do you avoid creating a bottleneck at the point where the contributions come together?

One very useful method is a code review workflow similar to those used in open source projects. In these projects hundreds of contributors might submit code and thousands might test it. Typically a core group of “maintainers” reviews submissions and selects the ones that will be included in the next release.

A code review workflow can be utilized in commercial environments as well. for example, the Assembla ticketing tool includes a merge request feature that allows contributors to submit code changes for review. Designated reviewers can review the submissions, hold online discussions about them, vote for or against accepting them, and make immediate decisions to accept or reject them

This code review workflow lets organizations manage the code review process and delegate the decision making for accepting contributions and assembling releases, which prevents these activities from becoming bottlenecks.

A code review workflow allows designated reviewers to vote on which contributions to include in the next release.

Streams for Managing Multiple Versions
Another common challenge among large projects is maintaining multiple releases and managing custom versions for individual customers.

Software vendors, for example, usually need to support several releases of an application at once. Bug fixes might need to be applied to many (but not all) of the supported releases. Enhancements to the current release might be retrofitted to the previous release and added to the upcoming release under development. Similarly, a service provider or enterprise IT department might be maintaining customized versions of an application for different customers or different business units within the enterprise.

perforce streams

It is much easier to navigate these complex scenarios with a tool like Perforce Streams. Perforce Streams not only helps development managers visualize the relationships between releases and versions, it guides release managers on where and when to apply bug fixes and feature enhancements when they are ready to be merged

Perforce Streams provide adaptable workflow for teams and promote efficiencies such as code re-use, automated merging, fast context switching, efficient workspace updates, and inherited workspace and branch views. An innovative addition to the Perforce branching and merging toolset, streams eliminate overhead, simplify common processes, and increase agility and scalability. In projects with a large volume of data, the time and performance savings are considerable.

Perforce Streams helps deploy bug fixes and enhancement across multiple releases and custom versions.

The typical perception of Agile development methodologies is that their benefits and promise are reserved for small, co-located teams. However, in the above sections we have seen how many, if not all, of the traditional Agile practices can be improved to the benefit of not only large teams, but large distributed teams as well. Ironically, this scalability has been achieved by employing the very processes and tools that the Agile Manifesto preaches against. However, while the tools enable scalability, they never require the sacrifice of developers’ freedoms or their ability to interact.

In these final paragraphs , tools will again be the focus for providing the solution for scaling one of the essential requirements of any Agile workflow: Continuous Integration with build and test automation. All the ideas addressed in the above paragraphs  will be reviewed along with detail on  how they fit together to make Agile scalable.

All of the examples provided can be implemented using software from Perforce, Assembla, Git and Jenkins.

Methods for Providing On-Demand Infrastructure

In a large project, the trickiest and costliest problems are found only when individuals put together all the pieces. It pays to find and fix these integration problems as early and often as possible.
Continuous Integration is a set of best practices in software development that supports project integration on a rapid, repeated basis . They are:

  •  Maintain a code repository
  •  Automate the build
  •  Make the build self-testing
  •  Everyone commits to the mainline every day
  •  Every commit (to the mainline) should be built
  •  Keep the build fast
  •  Test in a clone of the production environment
  •  Make it easy to get the latest deliverables
  •  Everyone can see the results of the latest build
  •  Automate deployment

The goal of is to perform a project-wide integration as often as possible. Striving to achieve this shapes your infrastructure, development practices, and attitudes.
Attitude is important. The entire team must commit to achieving successful integration at all stages of the project. For instance, a development task is not considered to be “done” until the feature appears in the integration build and is proven to work there. That shared commitment should make developers uneasy when they risk divergence by working in isolation for any lengthy period, e.g. when they are using an old build as a stable development base, or when they commit their changes their only infrequently. We cannot emphasize enough the importance of frequent integration. It really does reduce project risk.

Continuous Integration Tools in the Cloud
Organizations clearly need to invest in automated build and test processes if they want to scale up and deliver features faster and release more frequently. This investment can be expensive, but manual methods are obviously not scalable. Also, automated build and test processes tend to produce much higher software quality.

And if teams and contributors are highly distributed? Then the build and test tools must be accessible online, in the cloud.

Automated test tools like Jenkins can be integrated into the code review and merge workflows described earlier paragraphs. Whenever a contribution is accepted, a new version can be built and a series of automated tests can be run against it. Tools like Jenkins will then provide developers and the QA staff with detailed information on test results. Results from the test tool can even be used to vote to accept or reject contributions, as part of the code review workflow.

Automated test tools can provide detailed information on test results, and even vote to accept or reject contributions.

jenkins ci

Managing the impact of on-demand continuous integration is a logistical challenge for the version management service. Perforce addresses this challenge by providing flexible configurations of proxies and replicas to meet a variety of build demands.

supporting ci

In the earlier paragraphs,  some of the shortcomings of Scrum, such as lack of techniques to coordinate teams, assumptions about co-located teams and fixed release cycles that are unrealistic for many organizations, and a tendency to spend too much time in planning and coordination meetings was covered.

Continuous, iterative development is supported for different workflow methodology employed. With Perforce,  can:

  • Build and confirm your work from a private workspace before submitting your code
  • Execute automated builds and tests on specific branches upon check-in
  • Improve the quality of software and delivery time to market
  • Popular continuous integration tools, like Electric Commander from Electric Cloud, Parabuild from Viewtier, and Anthill Pro from UrbanCode, all support their own integrations with Perforce.

 A Scalable Agile process framework featuring the following was outlined:

  • A single prioritized backlog for all teams, so high-priority tasks always receive immediate attention.
  • Kanban processes with WIP limits, so teams don’t have to spend a lot of time in release planning, and to ensure that individual tasks are completed as quickly as possible.
  • On-demand resources, so each team can build and test its own contributions quickly and avoid making the QA lab a bottleneck.
  • A code review process that allows designated reviewers to accept or reject a large number of code submissions.
  • A “take what’s ready” approach to releases, so organizations could provide new functionality as frequently as required by customer needs and expectations.

The processes and tools that could facilitate Scalable Agile was discussed. These include online Agile planning tools, online collaboration, global code management, decentralized code management, ScrumBan processes, tools for on-demand merging and testing by contributors, code review workflows, stream-based tools for managing multiple releases and custom versions, and continuous integration tools provided in the cloud.

While the journey to Scalable Agile may be a long one, each of the steps down the path provides immediate benefits. The growing development groups consider:

  • Implementing ScrumBan, to start moving toward lean methods.
  • Deploying online planning and collaboration tools, to improve the effectiveness of distributed teams and contributors.
  • Deploying advanced code management platforms, to support distributed development and manage multiple releases and versions.
  • Begin investing in Continuous Integration and on-demand build and test systems.
  • Adjust the dial on continuous delivery gradually, to allow time for all your teams to adjust.

PEARL I : SCRUM : An Introduction on Origin,Evolution,Definition,Adoption and Future

PEARL I : SCRUM : An Introduction on Origin,Evolution,Definition,Adoption and Future


The first software development Scrum was created at Easel Corporation  in 1993 based on extensive research on successful projects worldwide, a deep analysis of the computer science literature, close collaboration with leading productivity experts, and decades of experience with advanced software technologies. Jeff Sutherland was the Chief Engineer for the Object Studio team that defined roles, hired the first Product Owner and ScrumMaster, developed the first Product Backlog and Sprint Backlog and built the first portfolio of products created with Scrum. They built the first object-oriented design and analysis tool that  incorporated round-trip engineering in the initial SCRUM. A second SCRUM  implemented the first product to completely automate object-relational mapping in an  enterprise development environment. Jeff was assisted by two world-class developers, Jeff  McKenna, now an extreme programming (XP) consultant, and John Scumniotales, now a  development leader for object-oriented design tools at Rational Corporation.

There were some key factors that influenced the introduction of SCRUM at Easel Corporation. The book “Wicked Problems, Righteous Solutions” (DeGrace and Stahl 1990) reviewed the reasons why the waterfall approach to software development does not work for software development today. Requirements are not fully understood before the  project begins. The user knows what they want only after they see an initial version of the  software. Requirements change during the software construction process. And new tools  and technologies make implementation strategies unpredictable. DeGrace and Stahl  reviewed “All-at-Once” models of software development which uniquely fit object oriented implementation of software.
In 1995, Jeff introduced the Scrum team to Ken Schwaber, CEO of Advanced Development Methods. Ken agreed that Scrum was a better way to build software and they worked together to formalize the Scrum development process at OOPSLA’95 . In the same year, Sutherland provided support for development of eXtreme Programming by giving Kent Beck all background information on the creation of Scrum and the results of two years of product development with the Scrum process from 1993-95. XP engineering practices evolved along with Scrum and the two leading Agile development processes work well together. Scrum and XP are the most widely used Agile processes worldwide and their creators are signatories of the Agile Manifesto.

One of the influences that sparked the creation of the Scrum Agile development process was a Harvard Business Review paper on Japanese new product  development by Takeuchi and Nonaka  . A key  component of their presentation was a chart showing product development separated into silo’s (Type A),  phases slightly overlapped (Type B), and all phases of  development overlapping (Type C). The Authors viewed  Type A product development as implemented at NASA as  an outmoded relay race process. Fuji-Xerox abandoned the  NASA approach for Type B which they called “Sashimi”  because slices of work overlapped with collaboration  between phases. Type C was implemented at Canon and  Honda. Takeuchi and Nonaka envisioned Types B and C as  a Rugby approach where multiple phases of product  development are done simultaneously. Scrum is a Rugby  formation and they viewed an “all-at-once” process as  similar to a Rugby team moving down the field passing the  ball back and forth

Jeff Sutherland got the name “Scrum” from the famous article “The New New Product Development Game,” which was published by Takeuchi and Nonaka in the Harvard Business Review in 1986. This article describes how companies like Honda, Cannon, Fuji-Xerox produced world class results using a scalable, team based approach to all at once product development. It also emphasizes the importance of empowered self organizing teams and outlines managements role in the development process.

On the first page of the article they write: “Companies are increasingly realizing that the old, sequential approach to developing new products simply won’t get the job done. Instead companies

in Japan and the United States are using a holistic method – as in rugby, the ball gets passed within the team as it moves as a unit up the field.

The Evolution

Evolution occurs in dynamic response to environmental demands.

After discussing the notion of various types of Scrum  with Certified ScrumMasters in Scrum Alliance workshops  and with development teams at Microsoft, Yahoo, Ariba,  Adobe, GE Healthcare, and other companies, it appeared  that the chart in article can be applied to a higher level of  thinking about three types of Scrum—going beyond the  thinking of Takeuchi and Nonaka

In a Type A Scrum, all development occurs in an increment within the time box of Scrum iteration called a Sprint. A side effect of this approach is downtime between iterations when reorganizing for the next Sprint. Nevertheless, well executed Sprints can double productivity and repeatedly deliver projects on time, within budget, with functionality precisely targeted to end-user demands.
By adding product definition tasks for the next Sprint into the current Sprint, a Type B Sprint allows work to flow smoothly from Sprint to Sprint. Product backlog requirements for the next Sprint are developed in the current Sprint. This has enabled some development organizations to deliver more working product than sales, marketing, or customers can absorb. The development bottleneck is eliminated and the company can adopt new strategies and create new products that were previously impossible to deliver.
Type C Sprint can be envisioned as overlapping Sprints by running software releases through the same Scrum team at the same time. This requires experienced Scrum teams, well designed product architecture, and automation of Product and Sprint backlogs. Throughput can be enhanced to deliver dozens of new releases of enterprise software annually. Competitors can be overwhelmed and market dominance achieved.

Type C Scrum increases speed of development,  aligns individual and corporate objectives, creates a  culture driven by performance, supports shareholder  value creation, achieves stable and consistent  communication of performance at all levels, and enhances  individual development and quality of life

To deal with simultaneous weekly and monthly  Sprints, along with quarterly major releases, a MetaScrum  was formed at PatientKeeper led by the lead Product  Owner. This is a weekly meeting that typical takes 1.5  hours and includes the CEO and other senior  management, as well as leadership from marketing,  development, quality assurance, installation, and support.
Takeuchi and Nonaka observed that collapsing phases of product development improved innovation, throughput, time to market, and product acceptance. As market pressures have evolved and changed, it is possible to collapse Scrum Sprints to create a dramatic increase in business opportunity.

Sutherland and Schwaber evolved  Scrum through trial and error at a number of companies during the  s – NewsPage, IDX Systems, Fidelity Investments, and PatientKeeper.  The Daily Scrum, the burndowns and  the Sprint Backlog were added, and  planning Sprints were dropped. !e  importance of self-managing, cross functional teams became apparent and a bedrock to Scrum.

Schwaber also collaborated with process control scientists at DuPont to tie Scrum to first principles in industrial process control theory, learning that the reason Scrum worked was
that it was empirical.

“In , the Agile Manifesto was formed,” says Schwaber. “!e signatories gathered in SnowBird because they felt their approach to software development had  something in common that was far better and more people-oriented than the  emerging favored process of the day, Rational Unified Process. !e principles  of the manifesto are the common touch
points that we agreed upon.”
Today, Schwaber notices that the term “Agile” is often used in a careless way.“Many people think that there are Agile processes. There aren’t. There are processes that conform to the Agile  Manifesto principles, such as Scrum and  Extreme Programming. However, the  word Agile is often used as a description  for ‘we aren’t using waterfall.’ That is not what Agile means!”
In Schwaber’s mind, Scrum and Agile  started emerging for two reasons: The Agile Manifesto was a rallying point for dissatisfaction and a new  approach. The emergence of new IDEs  that were as powerful as SmallTalk, like VisualStudio and Eclipse, were the technological enablers.

Scrum has streamlined software development — and professionals from around the world are starting to see the value of using Scrum. Of all the possible Agile frameworks used by companies, 66 percent are Scrum or Scrum variants.

Scrum has the power to transform project management across every industry, every business, and even across life in general. By using Scrum, teams become more Agile, discovering how to react more quickly and respond more accurately to the inevitable change that comes in the teams way. And by staying focused, collaborating, and communicating, you can accomplish what truly needs to be done — successfully.

Most important, Scrum is not unproven hype. It’s a solid and successful Agile framework that’s been applied to a variety of projects and teams. Universities use Scrum to deliver valued projects to clients. Militaries have relied on Scrum to prepare ships for deployment. In the automotive world, Team Wikispeed is using Scrum to build a fast, affordable, ultra-efficient, safe commuter car that should sell for less than $20,000.

So whether you’re working on the next smartphone app, managing logistics for a store, or planning a charity event, you should take a closer look at using Scrum. And Scrum Alliance can give you the proven framework, best implementation practices, and supportive guidance you need to achieve success.

The most profitable software product ever created (Google Adwords ) is powered by Scrum and the most productive large project with over a million lines of code (SirsiDynix and Starsoft) used a distributed, outsourced, Scrum implementation. CMMI Level 5 companies cut costs in half with Scrum while simultaneously improving quality, customer satisfaction, and the developer experience (Systematic Software Engineering). At the same time, Scrum remains the process of choice in small entrepreneurial companies where it has it roots.

Scrum Theory
Scrum is founded on empirical process control theory, or empiricism. Empiricism asserts that  knowledge comes from experience and making decisions based on what is known. Scrum employs an iterative, incremental approach to optimize predictability and control risk.  Three pillars uphold every implementation of empirical process control: transparency,  inspection, and adaptation.

Significant aspects of the process must be visible to those responsible for the outcome.
Transparency requires those aspects be defined by a common standard so observers share a  common understanding of what is being seen.
For example:

  • A common language referring to the process must be shared by all participants; and,
  • Those performing the work and those accepting the work product must share a common definition of “Done”

Scrum users must frequently inspect Scrum artifacts and progress toward a Sprint Goal to detect  undesirable variances. Their inspection should not be so frequent that inspection gets in the way  of the work. Inspections are most beneficial when diligently performed by skilled inspectors at  the point of work.
If an inspector determines that one or more aspects of a process deviate outside acceptable  limits, and that the resulting product will be unacceptable, the process or the material being  processed must be adjusted. An adjustment must be made as soon as possible to minimize  further deviation.
Scrum prescribes four formal events for inspection and adaptation, as described in the Scrum

  •  Sprint Planning
  •  Daily Scrum
  •  Sprint Review
  •  Sprint Retrospective


Scrum is based on small set of values, principles, and practices called collectively the Scrum Framework. Organizations using scrum shall use the scrum framework entirely perhaps not through the entire organization at once, but certainly within the initial teams that use scrum

Core Scrum — Values and roles

Values from the Agile Manifesto

Scrum is the best known of the Agile frameworks. It is the source of much of the thinking behind the values and principles of the Agile Manifesto, which forms a common basis for all of these approaches.

The Agile Manifesto values apply directly to Scrum:

  • Individuals and interactions over processes and tools. Scrum, like all the Agile frameworks and methods, relies directly on trust in teams, the individuals in the teams, and the way they interact. Teams figure out what is to be done, teams figure out how to do it, and teams do it. Teams identify what’s getting in their way, and they take the responsibility to resolve all the difficulties that are within their scope. Teams work with other parts of the organization to resolve the concerns that are outside their control. This is critical. Trying to do Scrum but undermining this primary focus on team responsibility and autonomy will generally lead to trouble.
  • Working software over comprehensive documentation. Scrum requires a working, finished increment of the product as the primary result of every sprint. Certainly there will be analysis work, design work, and testing work, all of which may need to be documented. But it is having a result (working software) that allows the organization to guide the project to success. This is critical. Scrum teams must produce a product increment in every sprint.
  • Customer collaboration over contract negotiation. The Scrum product owner is the Scrum team’s prime point of contact with the eventual end users of the product. The product owner is a member of the team and works collaboratively with the team to determine what needs to be done. In this collaboration, the product owner selects the most valuable next things to do, ensuring that the product has the highest possible value at every point in time. This is critical. The product owner needs to build a rich collaboration with the team.
  • Responding to change over following a plan. Everything about Scrum is designed to make sure that everyone has the information they need to make good decisions about the project. The project’s progress is represented by a real, running product increment. The backlog of things to be done is available for all to see. Progress, both overall and sprint by sprint, is clearly visible. Problems and concerns are discussed openly and dealt with immediately. This is critical. Scrum works well for teams that openly inspect what’s going on and adapt their actions to the reality. It works poorly for those who do not.

Scrum values

All work performed in Scrum needs a firm foundation of values for the team’s process and principles. With its emphasis on teamwork and continuous improvement, Scrum both creates those values and relies on them. The values are focus, courage, openness, commitment, and respect. From the team’s perspective, the values offer the following guides:

  • Focus. Because we focus on only a few things at a time, we work well together and produce excellent work. We deliver valuable items sooner.
  • Courage. Because we are not alone, we feel supported and have more resources at our disposal. This gives us the courage to undertake greater challenges.
  • Openness. As we work together, we practice expressing how we’re doing and what’s in our way. We learn that it is good to express concerns so that they can be addressed.
  • Commitment. Because we have great control over our own destiny, we become more committed to success.
  • Respect. As we work together, sharing successes and failures, we come to respect each other and to help each other become worthy of respect.

If an organization will let Scrum do its work, everyone involved will discover the benefits and will begin to understand why Scrum both engenders and relies upon these values.

The Scrum framework

Scrum is a framework for building a product.

Scrum is also a team process that begins when stakeholders need a product. The Scrum team includes three roles: the product owner, the ScrumMaster, and the members of the development team. These roles are further described below. The product is built incrementally over a series of short time periods called sprints. A sprint is a fixed time period, up to four weeks long but with a preference toward shorter intervals. During each sprint, the Scrum team builds and delivers a product increment. Each increment is a recognizable, visibly improved, operating subset of the product, meeting understood acceptance criteria and built to a level of quality referred to as the Definition of Done.

Scrum includes three essential artifacts: the product backlog, the sprint backlog, and the product increment. The product backlog is the list of ideas for the product, in the order we expect to build them. The sprint backlog is the detailed plan for development during the next sprint. The product increment, a required result of every sprint, is an integrated version of the product, kept at high enough quality to be shippable if the product owner chooses to ship it.

In addition, Scrum requires transparency within the team and with the stakeholders. Therefore the Scrum team produces visible displays of plans and progress.

Scrum also includes five activities or meetings. These are the backlog refinement, sprint planning, daily scrum, sprint review, and sprint retrospective.

SCRUM project planning uses lightweight techniques such as Burndown  Charts, as opposed to PERT charts. A PERT chart is only as good as the assumptions  inherent in the critical path represented on the chart. In agile development, the critical  path usually changes daily, rendering any given PERT chart obsolete within 24 hours.  The solution is using a technique to calculate the velocity of development. The neural  networks in the brains of team members are used on a daily basis to calculate the critical  path. This allows the plan to be recalculated and the velocity of “burndown” of work to  be computed. Team efforts to accelerate or decelerate the velocity of burndown allow a  team to “fly” the project into a fixed delivery date.

SCRUM is  the only agile methodology that has been formalized and published as an organizational  pattern for software development (Beedle, Devos et al. 1999). The process assumes that  requirements will change during the period between initial specification and delivery of a  product. It supports Humphrey’s Requirements Uncertainty Principle which states that for  a new software system, the requirements will not be completely known until after the  users have used it. SCRUM allows for Ziv’s Uncertainty Principle in software  engineering – uncertainty is inherent and inevitable in software development processes  and products (Ziv and Richardson 1997). And it support Wegner’s Lemma which states  that it is not possible to completely specify an interactive system (Wegner 1995). Most  software systems built today are object-oriented implementations which depend on  environmental inputs to determine process outputs, i.e. interactive systems.

Scrum roles

Product owner

The product owner has responsibility for deciding what work will be done. This is the single individual who is responsible for bringing forward the most valuable product possible by the desired date. The product owner does this by managing the flow of work to the team, selecting and refining items from the product backlog. The product owner maintains the product backlog and ensures that everyone knows what is on it and what the priorities are. The product owner may be supported by other individuals but must be a single person.

Certainly the product owner is not solely responsible for everything. The entire Scrum team is responsible for being as productive as possible, for improving its practices, for asking the right questions, for helping the product owner.

Nonetheless, the product owner, in Scrum, is in a unique position. The product owner is typically the individual closest to the “business side” of the project. The product owner is charged by the organization to “get this product out” and is the person who is expected to do the best possible job of satisfying all the stakeholders. The product owner does this by managing the product backlog and by ensuring that the backlog, and progress against it, is kept visible.

The product owner, by choosing what the development team should do next and what to defer, makes the scope-versus-schedule decisions that should lead to the best possible product.

Development team member

The development team is made up of the professionals who do the work of delivering the product increment. Scrum requires that the development team be a cross-functional group of people who, as a group, have all the necessary skills to deliver each increment of the product.

The development team members are expected to be available to the project full time, not splitting their time over numerous projects. They have the responsibility of self-organizing to accomplish each sprint goal, producing each new product increment according to each sprint plan.

The product owner makes an ordered list of what needs to be done; the development team members forecast how much they can do in one sprint, and they decide how they are going to do it.


The ScrumMaster is a “servant leader” who helps the rest of the Scrum team follow the process. The ScrumMaster must have a good understanding of the Scrum framework and the ability to train others in its subtleties.

The ScrumMaster helps the product owner understand how to create and maintain the product backlog. He or she works with the entire Scrum team to evolve the Definition of Done. The ScrumMaster also works with the development team to find and implement the technical practices needed to get to Done at the end of each sprint.

Another responsibility of the ScrumMaster is to remove impediments to the team’s progress. These impediments may be external to the team (such as a lack of support from another team) or internal (such as the product owner not knowing how to properly prepare the product backlog). That said, the ScrumMaster fosters self-organization, meaning that the team itself should remove issues wherever possible.

The ScrumMaster may facilitate meetings and always acts as a coach for the Scrum team, helping it execute the Scrum process. He or she helps team members work together and learn the Scrum framework, and protects them from both internal and external distractions. The ScrumMaster keeps the Scrum team on track, productive, and growing in ability.

Ultimately, the ScrumMaster is responsible for ensuring that Scrum is understood and in place, inside the team and outside. He or she helps people outside the team understand the process and the kinds of interactions with the team that are helpful (and those that are not). The ScrumMaster helps everyone improve to make the Scrum team more productive and valuable.

Artifact: Product backlog

The product backlog is crucial tool that enables the scrum team to achieve fast, flexible, value delivery flow in the presence of uncertainty.

The product backlog is an essential artifact in Scrum. It is an ordered list of ideas for the product, kept in the order in which the team expects to do them. It is the single source from which all requirements flow. This means that all the work the development team does comes from the product backlog. Every feature idea, enhancement, bug fix, documentation requirement — every bit of work the team does — is derived from a product backlog item. Each item on the product backlog includes a description and an estimate of the team capacity required to produce it.

Scrum Overview

The product backlog may begin as a large list or a short one. It may be vague or detailed. Typically, it begins short and vague and becomes longer and more concrete as time goes on. Product backlog items slated for implementation soon will be clarified, better defined, and split into smaller chunks as part of the product backlog refinement activity.

The Product Owner is accountable for maintaining the product backlog, although he or she may — and should — have help in producing it and keeping it up to date. Individual product backlog items may originate from the Product Owner, from team members, or from other stakeholders.

Activity: Product backlog refinement

Since product backlog items are often large and general in nature, and since ideas come and go and priorities change, product backlog refinement is an ongoing activity throughout a Scrum project. This activity includes but is not limited to:

  • Keeping the product backlog ordered
  • Removing or demoting items that no longer seem important
  • Adding or promoting items that arise or become more important
  • Splitting items into smaller items
  • Merging items into larger items
  • Estimating items

One key benefit of the product backlog refinement activity is that it helps prepare for upcoming sprints. Considerations include but are not limited to:

  • Whether each item entering the sprint truly represents an increment of “business value”
  • Whether the development team needs to be able to build each item within just a single sprint
  • Whether everyone on the team has a clear understanding of the purpose of each item

Depending on the nature of the product, other skills and inputs may be necessary. In every case, product backlog refinement is best considered as an activity for all team members, not just for the Product Owner.

Activity: Sprint planning

Each sprint begins with a time-boxed meeting called the sprint planning meeting. In this meeting the Scrum team collaborates to select and understand the work to be done in the upcoming sprint.

The entire team attends the sprint planning meeting. Working from the ordered product backlog, the Product Owner and the development team members discuss each item and come to a shared understanding of that item and what is required to complete it according to the current Definition of Done. All Scrum meetings are time-boxed. The recommended time for the sprint planning meeting is two hours or less per week of sprint duration. Because the meeting is time-boxed, the success of the sprint planning meeting is highly dependent upon the quality of the product backlog going in. This is why product backlog refinement is an important Scrum activity.

Scrum moves control from a central scheduling dispatching authority to individual teams doing the work.

In Scrum, the sprint planning meeting is described as having two parts:

  1. Determine what work will be completed in the sprint
  2. Determine how the work will be accomplished

In the first part of the meeting, the Product Owner presents ordered product backlog items to the development team, and the whole Scrum team collaborates to understand the work.

The number of product backlog items to undertake in the sprint is solely up to the development team. To decide how many items to undertake, the development team considers the current state of the product increment, the past performance of the team, the team’s current capacity, and the ordered product backlog. The development team alone decides how much work to take on. Neither the Product Owner nor any other agency can push more work onto the development team.

Often, but not always, the sprint has a goal. Having a sprint goal is a strong practice that helps everyone focus more on the essence of what needs to be done and less on small details that may not truly be important for the final product.

In the second part of the meeting, the development team collaborates to decide how to produce the next product increment in accordance with the current Definition of Done. The team does sufficient design and planning to be confident of completing the work during the sprint. Work to be done in the early days is broken down into small units of one day or less. Work to be done later may be left in larger units to be decomposed later.

Deciding how to do the work is the responsibility of the development team, just as deciding what to do is the responsibility of the Product Owner.

The Product Owner needs to be readily available to the team even if he or she does not attend this part of the meeting. However, the Product Owner may remain to answer questions and resolve misunderstandings.

Sprint planning concludes with the Scrum team reaching a common understanding of the quantity and complexity of what is to be accomplished during the sprint and with a rational expectation of being able to complete it. The development team forecasts the amount of work it will complete and commits to accomplishing it.

To summarize, in the sprint planning meeting the development team:

  • Considers and discusses product backlog items with the Product Owner
  • Ensures that all team members understand those items
  • Selects a number of items to achieve
  • Creates a sufficiently detailed plan to ensure that achievement

The resulting list of things to do is the sprint backlog.

Artifact: Sprint backlog

The sprint backlog is the list of refined product backlog items chosen for development in the current sprint, together with the team’s plan for accomplishing that work. It reflects the team’s forecast of what work can be completed.

With the sprint backlog in place, the sprint begins, and the development team develops the new product increment defined by the sprint backlog.


During the sprint, the development team self-organizes to produce the defined product increment. Self-organizing means that the development team determines how to produce and then does produce the product increment, in accordance with organizational standards, according to the Definition of Done.

Artifact: Product increment

The most important Scrum artifact is the product increment. Every sprint produces a product increment that must be of high enough quality to be given to users. The product increment must meet the Scrum team’s current Definition of Done, and each component of it must be acceptable to the Product Owner.

Additional indicators of visible progress

Scrum requires transparency within the team and outside the team. While the product increment is the most important way of creating transparency, the Scrum team will create any other artifacts that are needed to make sure that the status of the project is understood. Such artifacts commonly include burn charts and task boards.

Definition of Done

When the product increment is delivered, it needs to be “done” according to a shared understanding of what “done” means. This definition is different for every Scrum team, and as the team matures the Definition of Done will expand and become more stringent.

The Definition of Done must always include the notion that the product increment be of high enough quality to be shippable: The Product Owner could choose to release it immediately. The product increment includes the functionality of all previous product increments and is fully tested so that all completed product backlog items continue to work together.

Activity: Daily Scrum

The self-organizing development team uses the daily Scrum meeting to ensure that it is on track for attaining the sprint goal. The meeting takes place at the same time and place, every day. Each development team member gives three pieces of information:

  • What I have accomplished since our last daily Scrum
  • What I plan to accomplish between now and our next daily Scrum
  • What (if anything) is impeding my progress

There may be brief, clarifying questions and answers, but there is no discussion of any of these topics during the daily Scrum itself. However, many teams meet right after the daily Scrum to work on any issues that have come up.

The daily Scrum is not a report to management, nor to the Product Owner, nor to the ScrumMaster. It is a communication meeting within the development team that ensures that team members are all on the same page. Only the Scrum team members, including ScrumMaster and Product Owner, speak during this meeting (although other interested parties may come and listen). Based on what comes up in the meeting, the development team reorganizes the work as needed to accomplish the sprint goal.

The daily Scrum is a key element of Scrum, leading to transparency, trust, and better performance. It provides rapid recognition of problems and builds the team’s self-organization and self-reliance. All Scrum meetings are timeboxed; the recommended timebox for the daily Scrum is no more than 15 minutes.

Activity: Sprint review

At the end of the sprint, the Scrum team and stakeholders review the sprint’s output. The recommended timebox for the sprint review is one hour per week of sprint duration.

The central point of discussion is the product increment completed during the sprint. It is generally both wise and helpful for the stakeholders to attend this meeting, since they are directly interested in the product. This is an informal meeting to look at where the team is and to collaborate on how it might go forward. Everyone has input at the sprint review. Naturally, the Product Owner makes the final decisions about what happens next, updating the product backlog as appropriate.

Every teams will find its own way to handle the sprint review. A demonstration of the product increment is a common procedure. Groups also often discuss what they observed during the sprint and what product ideas came to mind. They discuss the state of the product backlog and talk about possible completion dates and what might be achieved by those dates.

The sprint review gives everyone present an overview of the current product increment; therefore, it is common to update the product backlog as part of the sprint review.

Activity: Sprint retrospective

The Scrum team improves its own process, always remaining within the Scrum framework. Therefore, at the end of each sprint, the Scrum team meets for the sprint retrospective. The purpose is to review how things went in terms of the process, relationships among people, and the tools. The team identifies what went well and what didn’t go so well, and it identifies potential improvements. The recommended timebox for the sprint retrospective is one hour per week of sprint duration.

Rinse, repeat

This Scrum cycle repeats for every sprint.

To sum up, the Scrum team’s members (the Product Owner, the development team, and the ScrumMaster) collaborate to create a series of product increments during short, time-boxed intervals called sprints. Each increment meets the Product Owner’s acceptance criteria and the team’s shared Definition of Done. The team works from a product backlog. During each sprint, the team begins with sprint planning to produce the sprint backlog, which is a plan for the sprint. The team self-organizes to handle the development, using daily Scrum meetings to coordinate and to ensure that they are producing the best possible product increment. The team performs product backlog refinement to prepare for the next sprint’s planning meeting. It ends the sprint with the sprint review and sprint retrospective, reviewing the product and the process.

Adoption and Future

“Scrum and Agile are similar to Lean Thinking. Scrum is a new way of doing business, but there won’t be that many that reap all of its benefits – such as productivity,  quality, engaged people, and maximized return on investment. American automobile companies were immersed  in running their operations top-down, using the principles of Scientific Management to try to plan everything.
Even while Toyota began to reach their market by using flexible lean techniques, they were unable to adapt. The change in perceptions, culture, and habits was too great.  Many places that are trying to shift from the predictive  approaches of waterfall and command and control are  having the same problems. The change in thinking is  particularly hard. The improved engineering practices  to support the change are also hard. Ken Schwaber predicted that only  those organizations with compelling reason to change  and management with insight and courage will succeed.”
“John Chambers, the CEO of Cisco, put his organization through such a change over the last four years and commented that it was the hardest thing he had ever  done.

“I predict that only 15–25 % of all organizations attempting to use Scrum throughout the enterprise will  succeed in making the change and reaping the benefits. As a result, they will out-compete those who weren’t  able to change and become dominant players in their markets”

In February and March of 2013, Scrum Alliance, and  ProjectsAtWork surveyed their  readership on use, knowledge  and views of Scrum.  The extensive survey of nearly 500 participants included  in-depth interviews and a literature review.  Participants from more than 70 countries responded to the  survey, with the United States leading at 35% and India second at 12%. The United Kingdom,Canada and Australia accounted  for 4% each, with Germany at  3% and South Korea, Mexico,Belgium, Brazil, Malaysia and New Zealand comprising 2%.

The majority of the participants are from the IT industry (41%),but a good representation camefrom Finance (12%), Government(6%), Healthcare (6%) and Telecommunications (5%), indicating the growing interest in Scrum outside IT. 53% of the participants were from organizations with 1,000 or fewer employees, yet 44% were with companies with annual revenues of $50M to $1B+. 28% were from organizations with ISO 9001 certification, but nearly half (48%) did not have any.

Key Findings
• While 41% of organizations are jumping into Agile waters without requiring a specific certification of their employees, 54% either agree or strongly agree that a certification such as the Certified Scrum Professional (CSP) improves their chances of sustained success.
• Culture is king in the Agile world—and according to a majority of respondents, organizations must create cultures that encourage collaboration in order to deliver value to their customers. This includes fostering self-organized teams and active support from management. Scrum facilitates all of these success factors.
• Scrum is the overwhelmingly preferred Agile method, used by 40% of respondents.The second-most popular method is Kanban, often using many elements of Scrum,a noteworthy trend as organizations seek to find for themselves what works for their specific domains and needs.
How Often and Why They Use Scrum
• In terms of current Agile approaches, Scrum leads the way: 40% of those sampled claimed to be adherents. It was followed by Kanban (15%) and Lean (11%). 19% of the participants used Scrum for up to a quarter of their projects that fall outside of IT, the
majority (38%) of which are in R&D, operations or production.
• 60% of the survey participants used Scrum regularly. 39% used Scrum more broadly throughout their business as one of their project management practices, while 16% used it exclusively for software development projects. 46% of the participants are deploying and managing Scrum projects within a Project Management Office (PMO), and 24% feel that managing and deploying Scrum projects this way is effective and successful.
• In terms of business priorities for Scrum projects, 41% feel that fulfilling customer needs is highest, while meeting budget, time and scope constraints as well as engaging in projects that drive innovation and market share followed with 36%. In terms of providing customer satisfaction while using Scrum, 27% feel having active senior management support is vital,  and 22% say a clear set of business goals for what gets achieved is necessary. That is why over half felt that cultural influences such as an open and collaborative environment—and empowered/self-organizing Scrum teams—are vital for facilitating Scrum; that can only be achieved through active support of management and clear business vision.

Scrum Adoption Factors
• The common belief that the vast majority of organizations adopting and integrating Scrum come from a Waterfall-like background was supported by the survey. 24% use Scrum for some projects while using Waterfall for the rest. 13% use Scrum exclusively, while 31% indicate no use of Waterfall. 23% felt it was a difficult transition from a Waterfall-based method to Scrum. Another perception, stated by 25% of respondents, was that there were no clearly identified metrics to identify and measure the successful delivery of Scrum projects.

Scrum will continue to grow because it is poised for the “Age  of the Customer.”What lies at the  heart of Agile is the  obsessive focus on  service to the  customer—the  mainstay of almost  any business.

Scrum will continue to expand outside of software development. Another adoption of Agile
outside of software development  presents itself in the article “Agile  Reinvents Retail,” published by  John Hitchcock of  on September 2012. The story  describes how a California retail  outlet called Oddyssea used Agile development principles to deploy  its retail operations

Another recent and famous  example of Scrum outside  of software development is  embodied in a sports car called  Wikispeed. Built by Joe Justice, a software engineer by trade, and  a team who entered the 2008  X-Prize competition, Wikispeed  was deployed using Scrum and  crowdsourcing. The team was able  to place tenth in a crowded and  highly competitive environment.
This was done by getting a working  prototype in three months for a  car that can go from 0 to 60 mph  in less than five seconds, weighs  just 1,404 pounds, has a top speed  of 149 mph and gets more than  100 mpg—all using Agile practices  and techniques.

Scrum is well suited for complex problems, where routine cookie cutter solutions does not apply.  In complex domains the ability to probe, explore, sense,inspect, adapt,and respond is critical.