How to Run a Sprint

Last Updated: September 16, 2021

Software developers are always looking for ways to build software "better, faster and cheaper." Scrum Sprint -- using Scrum (daily meetups) and running Sprint (a limited time for a team to work and complete a set of tasks) -- is one way to do that. (if you are looking for how to actually run faster, check out How to Sprint)

Steps

1
Prepare for the scrum sprint planning meeting. You can prepare a project wall chart with columns and rows for posting the sprint backlog, task assignments and the progress until completion.
- Get participant buy-in. Present the backlog of tasks (for developing a new system or enhancements to an existing system) to be achieved. Participants are the software development team (including the Programmers, Quality Assurance and Technical Writers), and the Product Owner (PO). The PO steers the sprint, and so if this contact person doesn't participate, the process is pointless (the PO is usually part of the development organization and has a customer of his/her own to understand and to please).
- Sprint is a development period for a product X during which requirements for X do not generally change except to remove obstacles. While discussing X at the planning meeting, a "new" item/feature Y might be discovered that should have been, but was not, on the Product Backlog until then. Considered in a larger context Y may require a rethinking of the backlog. If it is not essential to the sprint, Y might be tossed back onto the backlog not part of this sprint.^{[1]
  X
  Research source}
- Prepare the product backlog -- the prioritized list of all features or changes yet to be made -- a project-level "ToDoList".
- Organize the meeting - the product owner should host the meeting. A Scrum Master (not the PO) is the team member responsible to interface with the PO and the world outside the Scrum Sprint team, and to facilitate helping to coordinate with the PO so s/he can remove/resolve blockages that impede the team's work within the Scrum Sprint.
2
Hold the sprint planning meeting. Select a sprint duration, that is, how long the sprint will be. One month is a common duration. Durations are sometimes as short as one or two weeks.
- Identify which items/features from the product backlog make sense to work on first. Sometimes you want to pick the things you know involve the most technical risk, other times you may want to do the things that provide the highest business value. Some authors, like Kent Beck, suggest that you pick items for the first iteration that will allow you to build the whole system in a skeleton form. The product owner's input in this step is very important.
- Scope out and communicate the sprint goals and commitments (at the beginning of each Sprint, the Team and the Product Owner agree on a selection of backlog items from the list that will make up the Sprint Goal).
- Having selected which items to work on, your goal, the team next breaks the items down into tasks and sizes each task/feature. A feature might be split into multiple, smaller items for completion. In this way, the feature description and estimate are better defined, and sometimes new tasks/features are discovered.
- Once the tasks for the sprint have been identified, the team evaluates whether they have the capacity to complete the work planned for the iteration. If there is too much work, it will be necessary to reduce the number of items from the product backlog the team will attempt to complete in the current sprint iteration. If there are not enough tasks to keep everyone busy, the product owner may want to add another item and its tasks from the product backlog to the sprint.
Advertisement
3
Sprint! Work on completing each item in the sprint backlog. For an item to be complete, it must be coded, tested and documented.
- Each day, all the development staff (coders, testers, writers) gather for a short (usually 15 minutes) meeting, sometimes called a scrum. In this meeting, each member of the staff answers three questions very briefly (everyone listens to see how other tasks are progressing):
  1. "What did I do on the project yesterday?"
  2. "What am I going to do on the project today?"
  3. "What obstacles or impediments am I facing on the project?" -- the product owner may want to talk to some of the participants one-on-one, later.
- Track your progress. How much work is complete on the tasks? How much work is left (does someone need help)? The team may want to adjust their focus based on how the sprint is going.
4
Hold the sprint review. Participants should include the development team and the product owner at a minimum. Having customers and other people interested in the project is a plus.
- Set the context, remind the participants of which items were selected from the product backlog, and why.
- Demonstrate what the team has accomplished.
- The product owner provides feedback to the team on whether the features in this sprint match the product owner's expectations.
- Get feedback from the other participants, too. Customer feedback is especially valuable.
- If the team failed to meet any of the sprint goals, give status on those items.
5
Repeat. Use the feedback to decide how to improve sprint. Keep what works in sprints, and scrub what doesn't. You won't get better faster cheaper after one sprint. "Action reveals the next step."

Warnings

The process of frequent inspection and adaption will uncover all sorts of problems. Not fixing deep seated problems is a significant reason that people abandon daily Scrum/Sprint meetings.

⧼thumbs_response⧽
Helpful 1 Not Helpful 0
If the development team does not have anyone from the customer contact part of the organization involved in the sprint (someone who knows from the customer what is needed and wanted), then it is unlikely that the product will be successful.

⧼thumbs_response⧽
Helpful 1 Not Helpful 0