Scrum has the following moving parts, broadly:

• The Scrum methodology centers around time-limited iterations called Sprints:
  • A Sprint is defined as taking some fixed length of time that the development team (and sometimes stakeholders) can agree upon
  • Sprint durations are usually the same duration each time, but that duration can be changed, either temporarily or permanently (until the next time it's changed) if there is reason to do so
• Each Sprint has a set of features/functionality associated with it that the development team has committed to completing by the end of the Sprint.
• Each feature/functionality item is described by a user story.
• The team determines what user stories they can commit to completing, given the duration of the Sprint.
• The priority of user stories is determined by a stakeholder (usually a Product Owner), but can be negotiated.
• The team gathers periodically to groom the backlog, which can include:
  • Estimating the size of stories that don't have one
  • Adding task-level detail to user stories
  • Subdividing stories into smaller, more manageable chunks if there are functional dependencies or size-related execution concerns, and getting those approved by the relevant stakeholder(s)
• The team reviews the Sprint at the end, looking for things that went well, or for ways to improve on things that went less-than-well.
• The team meets periodically to plan the next Sprint.
• The team has a short, daily meeting (a stand-up), the purpose of which is to reveal what status has changed since the last update. The best-known format, though not the only one for these meetings, is a quick statement from each participant on:
  • What they have worked on since the last stand-up, complete or otherwise.
  • What they are planning on working on until the next stand-up.
  • What roadblocks they are dealing with, that someone else in the team might be able to assist with.

1. From beginning to end, a typical Sprint will unfold something like this, assuming all goes well:
2. Day 1 Sprint start-up activities:
   1. Stories and tasks are set up on the task board, whether it's real or virtual, all in a Not Started status, in priority order.
   2. Team members claim a story to work on, starting with the highest priority item. If more than one person is working on a single story, they each claim one of the tasks associated with it. Claimed stories are moved to an In Progress status on the task board.
3. Day 1 –day before end of Sprint: Development and QA.
4. Daily stand – up meeting (probably skipped on the first day).
5. Development:
   1. As tasks are completed, their status is updated on the task board to indicate as much.
   2. As stories are completed, they are moved to the next status on the task board after development. This column might be Dev-Complete, QA-Ready, or whatever other status description makes sense given the team's structure.
   3. If roadblocks are encountered, they are notified to the Scrum Master, who is responsible for facilitating resolving the blocking issue. If it cannot be resolved immediately, the status of the blocked story or task should be updated on the task board, and the developer moves on to the next task or story that they can tackle.

4. 4. As roadblocks get resolved, the items they were blocking reenter development status, and progress as normal from that point on. There is nothing to say that the developer who encountered the block initially has to be the one to continue work on the item after the block is resolved.

• Quality Assurance activities:
  • If QA staff are embedded into the development team, their processes are often similar to development activities, except that they'll start by claiming a story to test from whichever column indicates Dev-Complete items
  • Testing a story should include, at a minimum, the acceptance criteria of that story
  • Testing may well (and probably should) include functional tests that are not part of the acceptance criteria
• Story Acceptance: If there are any stories completed that haven't been accepted, they can be demonstrated and accepted or declined by the relevant stakeholder(s). Declined items will probably go back to the In Development or Not Started status, depending on why they were declined, and what can be done to resolve the reason for being declined.
• Sprint-Close Day:
  • Demonstration and acceptance of any remaining stories.
  • If time has not been available to do so before, preparation for the next Sprint should take place:
    • Sprint Planning, to prepare the user stories for the next Sprint
    • Backlog Grooming, to prepare and define details and tasks for any user stories that need those details
  • Acceptance of remaining stories.
  • Retrospective meeting—the team gathers to identify the following:
    • What worked well in the Sprint, in order to try and leverage what made it work well
    • What worked poorly, or not at all, in order to avoid similar scenarios in the future

All of the daily activities orbit around a task board, which provides a quick mechanism for easily seeing what's in progress, and what the status of each item is:

Scrum's priorities are its focus on transparency, inspection, and self-correction, and its adaptability to changing needs and requirements. The task board is a significant part of the transparency aspect of the methodology, allowing anyone with any interest to see at a glance what the current status of development efforts is. But it doesn't end there—there is a role known as the Product Owner, who acts as the central communications point between the development team and all of the stakeholders of the system. They attend the daily stand-ups, in order to have near-real-time visibility into progress, roadblocks, and so on, and are expected to speak for and make decisions on behalf of the entire collection of stakeholders. They are also responsible for connecting team members with external stakeholders in the event that questions or concerns arise that the Product Owner cannot address themselves. Their role is critical in assuring a good balance between providing transparency into ongoing development efforts to the stakeholders and and not burdening the development team with ongoing status reporting from them.

Scrum expects a fair amount of self-inspection in the process itself, and encourages a similar inspection of the results of the process—the software being created, and the practices and disciplines used in creating it—by prioritizing team openness and member intercommunication, providing a mechanism for raising visibility into risks and blocking conditions, and even, to some degree, by encouraging user stories that entail the smallest amount of effort to achieve a given functional goal. When concerns or issues arise, the emphasis on immediate communication and the ready availability of someone who can provide direction and make decisions resolve those issues quickly, and with a minimal degree of interference with the ongoing development process.

Scrum is, perhaps, one of the better methodologies from an adaptability-to-change perspective. Imagine a situation where a development team has been working on parts of a project for the first week of a two-week (or longer) Sprint. At that point, someone at the stakeholder level suddenly decides that a change needs to be made to one of the stories. There are several possible reasons—good, bad, or indifferent—for that sort of change to be necessary.

Perhaps the functionality that underlies the story is deemed obsolete, and no longer needed at all—if the story hasn't been completed, then it can simply be removed from the Sprint, and another story from the backlog pulled in to be worked on, if one is available that is no larger than the one being removed. If there's already code written against the story, it will probably need to be removed, but that's about it in terms of impact on the code base. If the story is complete, then the related code also gets removed, but no new work (additional stories) gets pulled in.

If the story is changed—the functionality behind it is being altered to better fit user needs or expectations, for example—the story gets withdrawn from the current Sprint in the same fashion as if it were being removed, at the very least. If there is time available to re-scope the story and re-insert it into the Sprint, that can be undertaken, otherwise it will be added to the backlog, probably at or near the top of the list from a priority perspective.

On occasion, it's possible for a Sprint to derail, but the methodology has expectations around how that gets handled as well. If a Sprint cannot complete successfully for any reason, it's supposed to stop, and a new Sprint is planned to pick up from where that one ended.

Some advantageous aspects of Scrum include:

• Scrum is well-suited to work that can be broken down into small, quick efforts. Even in large-scale systems, if additions to or alterations of the large code base can be described in short, low-effort stories, Scrum is a good process to apply.
• Scrum works well for teams that have reasonably consistent skillsets within their domains. That is, if all developers on a team can, for example, write code in the main language of the project without significant assistance, that's a better team dynamic than if only one out of six team members can.

At the same time, because of the structure involved in a Scrum process, there are some caveats:

• Since a Sprint represents a commitment to complete a set of stories and functionality, changing an in-process Sprint, even with a really good reason, is troublesome, time-consuming, and disruptive. That implies, then, that whoever is in the position of making decisions that could require in-process Sprint changes needs to be aware of the potential impacts of those decisions—ideally, perhaps, they would avoid Sprint-disruptive changes without really, really good reasons.
• Scrum may not lend itself well to meeting project- or system-level deadlines until or unless the team has a fair amount of expertise across the entire domain of the system and its code base. Iteration deadlines are at less risk, though they may require altered or reduced scope in order to deliver working software on an iteration-by-iteration basis.

• Development efforts and outputs become less predictable if the team members change—every new team member, especially if they join the team at different times, will have some impact on the team's ability to be predictable until the new team roster has had time to settle in. Scrum can be particularly sensitive to these changes, since new team members may not have all the necessary tribal knowledge to meet an iteration's commitments for a while.
• Scrum may not work well—perhaps not at all—if the members of a team aren't all in the same physical area. With modern teleconferencing, holding the daily stand-up is still possible, as are the other varied meetings, but Scrum is intended to be collaborative, so easier direct access to other team members tends to become important pretty quickly as soon as questions or issues arise.
• Unless it's pretty carefully managed not to, Scrum tends to reinforce skill-set silos in a team—if only one developer knows, for example, how to write code in a secondary language that the system needs, that person will be tapped more frequently or by default for any tasks or stories that need that knowledge in order to meet the iteration's commitments. Making a conscious effort to turn silo-reinforcing stories or tasks into a team or paired development effort can go a long way toward reducing these effects, but if no efforts are made, or if there isn't support for reducing these silos, they will persist.
• Scrum may be challenging if the system has a lot of external dependencies (work from other teams, for example), or a lot of quality control effort that developers have to contend with. This last item can be particularly problematic if those quality control requirements have legal or regulatory requirements associated with them. Assuring that external dependencies are themselves more predictable can go a long way to mitigate these kinds of challenges, but that may be out of the team's control.