Introduction
Scrum is a lightweight, agile framework that can be applied to almost any development project. Despite its relative simplicity, several moving parts, rules, and roles must be observed. To learn more, see our article on the Scrum framework or consider learning about Scrum development on a Scrum course, or even become a Scrum Master.
Outside of the planning, revision, and review, which helps facilitate development, Agile Scrum has a few ways of helping Scrum practitioners achieve their targets once the development cycle has started.
Like many other agile development frameworks, Scrum works in ‘Sprints’. A Sprint is a fixed time lasting anywhere between 1-4 weeks. During a Sprint a specific set of features or capabilities are created by the Developers working on a Scrum Team. A Sprint is where the development work occurs within a Scrum Team.
Sprints are a way of breaking down the project into bite-sized chunks. Planned work is based on feedback from previous Sprints and those features prioritized during the planning process.
In this article, we’re not going to focus on the overall Scrum framework. Instead, we’ll look at what happens once the major planning and preparation are complete and what each role should accomplish during Scrum development.
Sprint Planning
Every Sprint starts with some planning. The Product Backlog has already been refined to an appropriate level of detail, a suitable Sprint goal or target has been selected, and Developers know the resources available to them with which to accomplish the goals.
With that in mind, Developers, together with the Product Owner look at the list of available tasks in the Product Backlog. They select those that are feasible to develop, given the resources available and directly contribute towards that Sprint’s desired goal. The Team should have already evaluated each item in the Product Backlog. Developers should know who, what and how much time is needed to complete them.
Selection of work should be done by the Development Team (Scrum Team), as often the completion of one task may require multiple members of staff to collaborate which might lead to problems without adequate communication.
Sprint Planning outlines a small goal that fits neatly within the larger goals of the overall project. Now, the Development Team plans how to complete the work items they have selected. This is done by identifying and ordering the technical tasks involved.
The Product Owner does not need to be present for this. Scrum is all about autonomy and self-organizing teams. One of the primary ideas behind Scrum is that micro-management of the Development Team should be kept at a minimum so that once development has started, they can ‘get on with it.’ This shouldn’t be an issue providing the Product Backlog is neatly organized, goals have been clearly communicated, and all necessary tools have been made available to the Development Team.
Sprint Planning can be quite technical, and it is not expected that the Scrum Master or Product Owners will be heavily involved. However, the Product Owner should still be available to provide clarification and answer any questions the Development Team may have.
By the end of the Sprint Planning, the Development Team should be able to begin implementing the Sprint Plan immediately and with a clear understanding of how much work remains at any given point.
Sprint burndowns
Once Sprint Planning is completed, the Scrum Product Owner takes a back seat, and the Scrum Master assumes a more active role in development.
The Scrum Master is responsible for creating ‘information radiators’ – these can take the form of a Kanban board, white board, or flip charts with post it notes written with coloured pens. The purpose of information radiators is to keep the team informed on progress and allow them to ascertain information relevant to their immediate work quickly. That’s why they are usually low tech, and for co-located team members they can glance at the information from their desk.
A Scrum Team often uses Sprint burndown charts, which are graphical representations of the amount of work left and the time left to complete it.
Each team member is responsible for keeping the burndown chart updated.
Daily Scrum
The Development Team and Scrum Master meet at the start of each day to discuss upcoming work. This meeting should never take more than 15 minutes. The Daily Scrum meeting gives the opportunity to re-plan the Sprint Backlog as developers learn new strategies, discover new risks and opportunities or encounter problems that influence the work of others.
Each Development Team member should make clear the following:
- What they did yesterday to help the team meet the Sprint Goal
- What they intend to do today
- Any issues that are slowing them down.
Refining the backlog
This is not a scheduled event but rather an ongoing activity. The Scrum Development Team is left to decide how often to do this. While some teams might benefit from doing this at the end of each workday, it should take as little time away from development as possible.
The important thing is to make sure that the Product Backlog is refined by the end of the Sprint, so the Development Team can plan the next without delays.
A refinement session typically begins with the Product Owner presenting the current Product Backlog to the team. Developers then refine each task, examining them and changing the scope and definition of ‘done’.
For example, if a task undertaken this Sprint has proven to be a bit more of a challenge than anticipated, similar items in the backlog may be broken down into smaller tasks.
Collaboration
In Agile, teamwork is so important that the role is often referred to as a Development Team member rather than developer.
Each Development Team member is jointly responsible for the progress of work. Any problems or failures are jointly owned by the team, as well as their successes. Collaboration is not restricted to events such as the Daily Scrum but applies to everything the team does throughout each Sprint.
Sprint Reviews
Unlike the Sprint Retrospective, which occurs outside the Sprint, the Sprint Review occurs within the Sprint time-box. Sometimes the Product Owner and stakeholders may be invited to attend this meeting. However, it’s still a valuable exercise if information can be gathered in an email or presentation to be passed on for later review.
