Agile scrum methodology is a project management system that relies on incremental development. Each iteration consists of two- to four-week sprints, where the goal of each sprint is to build the most important features first and come out with a potentially deliverable product.
One of the most popular agile methodologies in use today. Scrum is a lightweight software development methodology that focuses on having small time-boxed sprints of new functionality that are incorporated into an integrated product baseline. Scrum places an emphasis on transparent customer interaction, feedback and adjustments rather than documentation and prediction.
With scrum projects, the requirements for the project do not have to be codified up-front, instead they are prioritized and scheduled for each sprint. The requirements are composed of ‘user stories’ that can be scheduled into a particular release and sprint:
Scrum is often deployed in conjunction with other agile methods such as Extreme Programming (XP) since such methods are in reality mostly complimentary, with XP focusing on the engineering (continuous exploration, continuous integration, test-driven development, etc.) and Scrum focusing more on the project management side (burn-down, fixed scope for sprints/iterations) as part of the product management. So, project managers should choose elements of the Scrum project management methodology and other methods/tools together for the specific project. Since Scrum is a more defined project management methodology in terms of tools and processes, it is often easier to adopt from day one with less initial invention and customization.
Traditionally projects are delivered in a series of phases that are based on increasing levels of certainty around the system being built:
However, this approach has many drawbacks:
When using the agile Scrum methodology, the key benefits are:
Scrum is useful for a wide variety of businesses and projects, and is in fact used in the majority of software development projects where there is the ability to get real-time feedback from users and customers.
We have seen customers in such disparate industries such as finance, banking, insurance, life sciences, transportation, logistics, manufacturing, education and industrial systems adopt Scrum as their primary software development lifecycle. Even the industries most associated with waterfall approaches – aerospace, defense and automotive – are now adopting Scrum. The ability to live update software in satellites and cars means that iterative approaches are now more feasible.
One of the challenges in some industries is that even though with Scrum you can develop and release new production-ready code in two-weekly sprints, you need to produce reports, documentation and paperwork to allow that functionality to be used. This has previously hampered Scrum adoption in some industries.
The new trend in agile Scrum projects is to simply define the required regulatory documentation and paperwork as part of the product, and ensure that the automated lifecycle management systems in place can generate the documentation automatically from the project teams as part of each sprint. We call this “Agile Compliance”.
There can many different roles in a Scrum project, but there are three core roles:
All of these people are committed to the scrum project, and are augmented by various other specialist roles such as testers, test automation engineers, cybersecurity experts, user experience designers, business analysts, functional experts, and performance/load engineers.
In addition, there are some ancillary roles that are not core to the Scrum project team, but are heavily involved in the project outcome:
We will define the key roles below.
The product owner role on a Scrum team is the person that is responsible for managing the backlog of work and overseeing releases and sprints. They act as the project manager for the Scrum team, although the agile community generally doesn’t use that term. The product owner is responsible for representing the voice of the customer (and other external stakeholders), ensuring that all development work reflects the needs of the end-user.
According to the official Scrum Guide, the primary responsibility of the product owner is to manage the product backlog. This means ordering and prioritizing work, optimizing the value of the work and ensuring all team members understand what work needs to be tackled next.
This role is responsible for helping the team to follow the Scrum process, and focuses almost exclusively on the process itself. They are not involved in the decision-making, but act as a lodestar to guide the team through the scrum process with their experience and expertise.
In contrast with a traditional project manager, they are not necessarily involved in agile release planning. That’s done by the product owner and the Scrum team. A Scrum Master doesn’t act as a pseudo-project manager since a Scrum team is meant to be self-organizing. The Scrum Master is the glue that holds the project together by facilitating, though not participating, in the daily Scrum meeting (one of the Scrum ceremonies we will discuss later). Scrum Masters help the team maintain their burndown chart and set up retrospectives, sprint reviews and agile sprint planning sessions.
According to the Scrum Alliance, a typical Scrum team (called a Development team in the Scrum 2020 revision) consists of five to nine people and generally includes the typical functional roles required to complete the project. In software development, that usually means architects, testers, developers, and designers; but could also include security, performance, hardware and other experts.
The team acts collectively to determine how to achieve their goals. The specific features they work on are determined by the priority established by the product owner. The way they work is guided by the Scrum process, as monitored by the Scrum Master. Everything else is up to the team to manage, with the Scrum Master providing as much support as needed to allow that to happen. For example, each team member can take a user story from the prioritized product backlog, then decide individually how to execute that work.
This level of autonomy is a cornerstone of Scrum. It encourages strong bonds between team members and helps create a positive working environment. While the idea of a team exists in waterfall projects as well, in that environment the team is functionally managed by the project manager, rather than being self-managed.
In practice, Scrum consists of the following key artifacts:
We will describe each of these in turn.
A product backlog is a list of everything that needs to be achieved on a project, broken down into individual items. This is where the baseline requirements of every feature needed for the end product are prioritized by the product owner for the Scrum team.
It is not a list of unchangeable tasks, and it often evolves over time. For example, if there is a change in the business environment, marketing conditions or technical demands, the product backlog will reflect those changes. Product backlogs are often represented using a Scrum board.
The product backlog is usually made up of several different types of items:
The backlog grows as the product is being built. When changes are added they can include more detail, estimates or a change in priority. The product owner and the team are regularly working on refining the product backlog. This can occur at any time.
Refining the product backlog includes activities such as reviewing the user stories of the highest priority at the top of the backlog, and asking the product owner questions about them. This includes, if necessary, deleting user stories and then writing new ones. This is followed by reprioritizing the product backlog.
Then these new user stories need to be estimated in terms of their relative size (usually in story points), as compared to other user stories in the backlog. The user stories should be prepared for future releases and sprints, while not losing sight of the big picture of the overarching product architecture as the backlog evolves.
A release is most frequently associated with a major functionality delivered according to the product roadmap. The release backlog is the list of prioritized user stories from the product backlog that are currently included into the next set of scheduled releases. Depending upon the organization’s cadence for releasing functionality, a release may consist of two or more Scrum sprints.
Alternatively, the product owners may also use the roadmap to align with calendar-based releases if an organization uses yearly, half-yearly, quarterly, or monthly releases.
Some organizations may directly go to releasing sprints directly if the organizational governance and compliance framework allows such an operating cadence. So, release planning is often used when agile is adapted, but unlike Sprint planning, is an optional activity. If an organization does not manage using releases, then, the Sprints will need to be mapped directly to the product roadmap instead.
The sprint backlog is the part of the product backlog that the team will be working on in their sprint. Think of it as the to-do list for the sprint.
The sprint backlog is further broken down into tasks for the team to execute. Every item on the sprint backlog needs to get developed, tested and documented. The product owner helps the scrum team come up with a sprint backlog during their sprint meeting.
The sprint backlog is often represented as a task board, which is broken up into columns that represent the workflow. They tend to have the following titles:
You may have other steps such as Tested or Verified, depending on your exact Scrum process. Sometimes you will have a simpler task board that has just three statuses: Not Started, In Progress and Done:
The sprint backlog, like the product backlog, is a living document and is changed by the scrum team. Work is discussed regularly at the daily scrum and the sprint backlog is modified as needed. This is all happening during the short sprint, and only the scrum team can make these changes as they occur during the sprint.
The definition of done (DoD) means that all aspects of a user story have been completed in a sprint backlog. The scrum team must have a shared idea of what being done means. They should create a definition of done and use this as a checklist as they work on their user stories.
The scrum team can create their DoD during the first sprint planning. It can then be iterated on during their sprint retrospectives. That doesn’t mean a DoD is static. It can change dramatically over the course of the project.
Sometimes a team will create a standard DoD template that will be used on all user stories in the project.
This is the most important scrum artifact. The product increment is all the product backlog items that have been completed during a sprint.
Each sprint is potentially creating shippable product increments, and so the product increment must fit into the team’s definition of done and be acceptable to the product owner.
The definition of done is a shared one among the scrum team, although it is different for each scrum team. The definition of done evolves as the team matures: it grows more expansive or stringent as the project continues.
The product increment is not only the sum of all the project backlog items completed over the course of a sprint, but it is also the value of the increments over the last number of completed sprints. This is transparency not only for the team but for the stakeholders in terms of where the product is at the moment.
Progress throughout the sprint is measured by the number of story points left to complete in that sprint and displayed using a ‘burndown chart’.
In addition, during the sprint, you can use a task burndown chart to view the individual Scrum team tasks to get more granular progress reporting.
A story point is an arbitrary measure of the complexity or effort required to implement a user story. The only requirement is that story points are consistently applied. The rate at which story points are completed is called the velocity.
A Scrum event or “ceremony” is simply a regular meeting on an agile project, such as the sprint planning meeting, the daily stand-up, the sprint review, and the sprint retrospective. Scrum events or Scrum ceremonies foster team collaboration and make sure that there’s a constant line of communication among the scrum team members through the product or software development life cycle. We will discuss each of the ceremonies in turn:
It is imperative that a roadmap exists so that the sequences of releases can be identified and the backlog items are appropriately refined and mapped to the releases and sprints. This release planning activity precedes sprint planning but serves as a good foundation to ensure that the required stories are in the backlog to deliver on the product roadmap.
Collaborating with the team, the product owner may extend the release planning with the continuous backlog refinement activity. This process will help identify any stories from the team’s delivery angle that otherwise would be missed if the release planning is not done. Collectively, these releases then unleash the story the product development team can use to report to the project stakeholders.
Contrary to release planning, sprint planning focuses on the work committed by the team to be done immediately after planning is completed. It is important to note the keyword – immediately. Generally speaking, sprints are expected to start immediately after the planning is done and the previous iteration ends because the team maintains the operating cadence and also has the context of work already delivered.
Using the product backlog, teams start with the highest priority items and determine how to achieve this objective. A good tip when sprint planning is to do the due diligence and only start with items that are ready. Also, remember that planning is a short process, so don’t get bogged down in the details. Just get to work on meeting the objectives. Keep the plan collaborative. The team should also ask the product owner and stakeholder questions.
The daily standup is where the team members discuss their progress confirming their commitments to the sprint goals and risks impeding their progress. These should ideally be 15-minute meetings where everybody in the scrum team talks about the tasks they’ll be working on during the day and share any roadblocks or difficulties they’re facing. There’s no need to make this daily scrum meeting longer, as there are other meetings such as sprint reviews and sprint retrospectives to explore more complex topics.
Please note that the ownership is for the team members to discuss the progress. This daily standup is not a status check meeting where the product owner or other team member acts as a status coordinator. Another popular activity that happens in the daily standup is an update on the burn-up, burndown, and velocity charts.
The review is where the team demonstrates the product increment on the work completed. While the product owner can review, accept, and even release the work product throughout the sprint, the review presents an opportunity for the team to demonstrate the functionality. These “show-and-tell” review sessions are recommended for the business stakeholders beyond the delivery team.
Based on the product increments delivered, new items may be added to the product backlog. However, the accountability rests with the product owner to accept the work completed or reject it based on the definition of done.
The sprint retrospective meeting gives the scrum team a space to reflect on the last sprint and determine what went well and wrong. Stakeholder and customer feedback is also gathered in order to prioritize user stories and improve product performance.
The goal of the retrospective is not to identify the person observing the improvements and suggesting the recommendations but to capture the improvements and recommendations. To facilitate this goal, many techniques can be utilized.
One common approach is to break the discussion down into three areas:
One of the key tenets of the agile manifesto is to "embrace change", in contrast to traditional methodologies, you deliberately request customer and end user feedback as frequently as possible (at the very least, after each completed release or sprint of work is delivered) so that things that have been learned during the sprint are used to change the priorities of the next items in the backlog. This process is called backlog grooming or backlog refinement.
For example, you may have a high-level roadmap with some features that make sense from a market standpoint. However, as you start to deliver features, you realize that your initial customers really need other features that you hadn't thought of, solving business problems that you didn't know existed.
With an agile approach, you should use this feedback to reassess what's in your backlog:
The idea developed by Kent Beck was to use best programming practices but take them to the extreme – hence the name. As such, none of the individual concepts of XP are really new, but their application and combination is what makes XP different, or at least did in the 2000s, which is when it initially became popular. XP advocates adaptability; recognizing that each project faces different problems, applying those methods that will work and discarding those that will not. Partial XP therefore becomes a true possibility, often combined with Scrum, which has gaps in its definition particularly suited to adoption of XP practices.
XP embraces standard agile principles such as short iterations; requirements being loosely defined with user stories until they are needed; almost immediate and regular testing; close, on-site stakeholder involvement with a rapid feedback loop; and team responsibility for success or failure.
As is necessary for Agile projects, the XP team expects and accepts changes in requirements based on feedback from stakeholders and the obligatory high level of communication within the team. Intense communication is necessary because everyone is required to understand the system as a whole so that anyone can work on and change any of the code. Quickly written code is often used as a means to explain ideas and try out designs. With short iterations comes regular layering of new functionality, thus refactoring is encouraged in order to consolidate separately written parts into a more efficient whole.
Testing taken to the extreme means using as many testing techniques as necessary, as often as possible. Methods include unit testing, acceptance testing, integration testing and test-first programming. Some of these approaches also include test driven development (TDD) and behavior driven development (BDD).
Pair programming is part of XP, the idea being that two heads are better than one. Using only one workstation, one person writes code while the other observes, injecting ideas, pointing out potential problems and thinking about the ‘big picture’ as the code is written. Roles are reversed frequently and the pair work as if joined at the hip. If a pair get too comfortable with one another they may begin to think alike and two heads thinking as one is no better than one head, defeating the purpose. Pairs should be split up and reassigned when this happens. While pair programming does increase staffing needs, it is an excellent technique for building in quality which is an Agile ideal.
Finally: Simplicity. The simplest solutions are encouraged, addressing the immediate problems, not problems that might arise tomorrow. This helps everyone to remain focused and meet deadlines but can result in considerable redesign and refactoring over time. To avoid architectural dead-ends, spike solutions are recommended, whereby the team creates user stories to prove out areas of most technical or conceptual risk. This, together with refactoring build into every iteration, prevents the system becoming atrophied and unable to support future needs.
One of the reasons XP is so popular is its flexible nature. It is easy to combine features of XP with other ideas; indeed, XP is more about technique than process and so dovetails well with process-centric approaches such as that of Scrum.
When your company requires a system to manage your Scrum or XP projects, there are a lot of choices in the marketplace. However, if you want the most complete solution that can handle your user stories, backlog items and acceptance tests there is only one solution.
The list of user stories, requirements, defects and features is called the Product Backlog. SpiraTeam lets you organize the backlog by component, package or priority. You can order and categorize them by simple drag and drop editing. This is called backlog grooming or refinement.
The requirements, user stories, tasks, test cases and outstanding bugs and issues can be scheduled against the different iterations / sprints in the release. The system will calculate the available effort as items are added.
SpiraTeam is a complete Scrum project management system in one package, that manages your project's requirements, releases, sprints, tasks and bugs/issues. Designed specifically to support agile methodologies such as Scrum, it allows teams to manage all their information in one environment.
|Requirement||User Story||Backlog Item|
|Test Case||Acceptance Test||Acceptance Test|
In addition to a powerful planning board for managing user stories, epics and backlog items, SpiraTeam includes an easy to use set of boards for managing tasks within the Sprint.
SpiraTeam lets you view the tasks associated with each of the user stories within the Sprint and see the completion status at a glance.
SpiraTeam provides reporting dashboards of key project quality and progress indicators - requirements test coverage, task progress, project velocity, as well as top risk and issues – in one consolidated view that is tailor-made for Scrum and Extreme Programming projects as well as supporting any legacy/hybrid waterfall projects.
In addition, we provide superb technical support that ensures that enquiries and questions are dealt with in a timely and professional manner.
To learn more about SpiraTeam and how it can improve your Scrum project management methodology, please:
One of the key tenets of Scrum and XP is that fully integrated, tested and releasable code is available at all times. When you couple this requirement with the accelerated timeframes possible with Scrum, clearly manual testing is not going to cut it. You need a test automation solution that can be integrated fully into your development process and that be adapted to your changing needs:
Rapise is the most powerful and flexible automated testing tool on the market. With support for testing desktop, web and mobile applications, Rapise can be used by testers, developers and business users to rapidly and easily create automated acceptance tests that integrate with your user stories and other backlog items in SpiraTeam.
One of the obstacles to implementing test automation on an agile Scrum or XP project is that the application’s user interface may be changing frequently, with new pushes to production daily. Therefore, it is critical that tests created one day, continue to work seamlessly the next.
Rapise comes with a built-in machine learning engine that records multiple different ways to locate each UI object and measures that against user feedback to determine the probabilistic likelihood of a match. This means that even when you change the UI, Rapise can still execute the test and determine if there is a failure or not.
To learn more about Rapise and how it can improve your Scrum and XP software testing please:
And if you have any questions, please email or call us at +1 (202) 558-6885