What is an agile sprint?
A Sprint is part of the Scrum framework. It is a short, time-boxed period during which the Scrum Team completes a certain amount of work. This work is pulled from the Product Backlog to make up the Sprint Backlog.
The ‘Agile’ part comes from the use of Agile principles. To run a Sprint, you should be familiar with the Agile Manifesto. Sprints fulfill the Agile principle of delivering working, valuable software frequently. Sprints also enable teams to respond to change whilst still following a set plan.
Who should be involved in an agile sprint?
Sprints involve the entire Scrum Team, made up of:
- The Developers – the people in the Scrum Team that complete the work assigned to the Sprint. They are accountable for helping to create the plan for the Sprint (the Sprint Backlog), adhering to the Definition of Done, and adapting their plan towards the Sprint Goal,
- Product Owner – in charge of Product Backlog management. This person is accountable for- clearly communicating the Product Goal and the Product Backlog items, ordering the Product Backlog, and ensuring it is transparent, visible, and understood.
- Scrum Master – leading the Scrum Team with an empirical approach, and stakeholder management. The Scrum Master helps the team improve its effectiveness by improving Scrum practices, coaching team members in creating high-value increments, removing impediments to Development Team’s progress, and ensuring all Scrum events are successful and productive.
A benefit of the Sprint structure is that the team is self-organising. Self-organising teams can easily take initiative, focus on team contributions, concentrate on solutions, co-operate, continuously improve, and take steps to prevent emergencies.
How agile sprints work
The Sprint works towards a Product Goal – a measurable, actionable target for the Scrum Team, with a clear purpose.
A successful Sprint will offer many chances for inspection, which allows for improvement of the product. The Scrum events below are perfect opportunities for inspection, which encourages continuous learning, transparency, and adaption.
There are a few stages to a Sprint: The Sprint Planning meeting, the Daily Scrum / Stand Up, the Sprint Review, and the Sprint Retrospective. Following these steps are key to planning your own successful Sprint.
During a Sprint:
- no changes are made that would endanger the Sprint Goal.
- quality does not decrease.
- the Product Backlog is refined as needed.
- scope may be clarified and renegotiated with the Product Owner as more is learned.
Planning a sprint
Sprint planning meeting
As you may have guessed from the name, this meeting is key to planning. In attendance are the Development Team, the Product Owner, and the Scrum Master. It is a collaborative event, where the team will ask themselves:
- What is the Sprint Goal? Or, why is this Sprint valuable?
- What work needs to be done?
- How will it get done?
Each Sprint should have an objective set by the Product Owner, and the team then decides which items from the Product Backlog will achieve this goal.
Items are chosen, and these items are the pulled from the Product Backlog to make up what is called the Sprint Backlog. As the Sprint happens, products are moved from the Sprint Backlog to ‘In progress’, and then to ‘Done’.
Daily scrum / stand up
The purpose of the Daily Scrum is to inspect progress toward the Sprint Goal and adapt the Sprint Backlog as necessary, adjusting the upcoming planned work. This event is for the Development Team.
As work progresses over the course of the Sprint, the team checks in at the same time each day during the Daily Scrum or Stand Up. This meeting is usually short and snappy – only around 15 minutes – and serves to highlight any roadblocks or challenges the team might be experiencing and gives the team an opportunity to discuss how to resolve these. The Daily Scrum improves communication and allows adjustments to be made to upcoming work. It also eliminates the need for excessive meetings throughout the day.
Sprint review
After the Sprint has come to its end, the team discusses what business has been achieved. The Development Team, the Product Owner, the Scrum Master, and any additional stakeholders will be in attendance.
This is a good opportunity to demonstrate completed work to stakeholders or the wider team before it goes live to the client or customer.
Sprint retrospective
Finally, it’s time for the Sprint Retrospective. The Development Team, the Product Owner, and the Scrum Master attend.
This is an opportunity to reflect on any blockers or ‘lessons learnt’ over the course of the Sprint and create actionable solutions for the next iteration. Any improvements can even be added to the Sprint Backlog for the next Sprint.
The result is a deliverable increment of value, and one more step towards the Product Goal. Ta-da! The Sprint is complete, onto the next one, which starts immediately after the last one ends.
The Scrum framework diagram below shows how this Sprint process fits more widely into Scrum methodologies.
What makes a good sprint goal?
A good Sprint Goal has three characteristics: focus, flexibility, and purpose.
Does it provide enough focus so that we can have a working Product Increment that provides value by the end of the Sprint?
Does it provide enough flexibility so that we can adapt our plan as we uncover new learning and complexity?
Does it provide a sense of purpose so that we can see the value and meaning in our work?
What is the sprint backlog?
The Sprint Backlog is the specific plan for the developers for that particular Sprint.
Everyone should be able to view it, and it is an up-to-date picture of all the work needing to be done. It should act as a roadmap for how all work is going to get done and is flexible according to any changes or blockers. Items for the Sprint backlog are drawn from the Product Backlog.
How long are agile sprints?
Agile Sprints must be a fixed period of around one week to one month. It is important to keep Sprints short, because when a Sprint is too long the Sprint may become irrelevant (i.e., the Sprint Goal or end product might change drastically), it could become overly complex, and risk may increase.
If a Sprint is too short, it will put pressure on the development team and could lead to rushed work, or it could fall short of what the Sprint was intended to accomplish.
Software such as Jira can be used to forecast progress in burn-downs, burn-ups, or cumulative flows. But it’s importance not to rely solely on these automatic readings. Empiricism – relying on feelings and our own knowledge – is important when running a successful Sprint.
Why use sprints in agile?
Splitting up work into Sprints has numerous benefits for an Agile team. It splits work into more manageable chunks and allows teams to deliver work faster and more frequently without compromising on quality. Sprints also enable better flexibility and adaptability. It encourages more frequent communication, allowing teams to control projects through detailed understanding of past work to predict future workload.
Fool-proof sprints: dos and don’ts
Do:
- Make sure your team understands the need for clear, concise backlog items.
- Make sure the entire team understands the product goal.
- Capture any details needed for your team to get started on the task in a project management or collaboration tool like Jira.
- Make sure to prioritise your backlog by dependencies and deadlines.
- Budget enough time for review or any roadblocks that may need to be overcome.
- Make sure you schedule in leave or team meetings.
Don’t:
- Don’t set up the team for failure by pulling in too many tasks from the Product Backlog.
- Don’t allow anchoring to happen! Anchoring is when an authoritative person, such as a Product Owner, makes an assertion early in a conversation. This means others might be reluctant to express a counter opinion, harming team morale. Instead, practice active listening and encourage open conversations.
- Don’t take on high-risk work or anything too vague! It’s best to get as much information about the task as possible before scheduling it in. Break things down further if they are uncertain or consider scheduling the work in later on.
- Don’t forget to listen to your team! If anyone is expressing concerns, adjust workload capacity as needed.
Agile sprints summary
-
- An Agile Sprint is a short time-boxed period, of around one week to a month, where a certain amount of work gets done.
- A Sprint is made up of the Developers, the Product Owner and the Scrum Master.
- A Sprint works by holding a Sprint Planning meeting, Daily Scrums, the Sprint Review, and the Sprint Retrospective.
- The Sprint Backlog is items taken from the Product Backlog for that particular Sprint.
- There are many reasons to use Sprints, but mainly because it splits up work into manageable chunks to consistently deliver value, whilst staying flexible. It also allows team to predict future workload according to past tasks.
Agile sprint training with QA
Want to learn more about Agile Sprints? QA has a range of different Agile training courses to help you get clued up and certified in Agile.