As part of doing agile development, there are all these regular scrum ceremonies that need to be done. It’s more important to know why some of these activities are done instead of mindlessly following some structure and say that you’re “doing agile”. With this said, first you need to know the structure of a sprint.
What is a sprint
A sprint is a short period of time for a development team to achieve the sprint goal, which could be to ship incremental updates or product features. Within this timeframe, a scrum team takes tasks (known as stories) from a prioritized backlog, build the feature, test it, and deploy it through their continuous integration system.
How long should a sprint be?
Typically, teams work in 1-2 week sprints, but they can last as long as a month or two depending on your group. There is no hard-and-fast rule about an ideal length, but the sprint length typically depends on the type of product that is being developed. What is important is that the sprint duration, once agreed, should remain at a consistent cadence. This rhythm is helpful for future estimation, creating velocity and burndown charts. Plan sprint durations around how long you can commit to keeping change out of the sprint.
How much work should be done in a sprint?
Since a sprint is a fixed timeframe, the amount of work done should be predictable after a few iterations. Once the team has done a couple of sprints, they should be able to know how many story points they are able to accomplish within a sprint. Proper story point estimation is key during the story time meeting to match work done with the velocity of the team. More information about story time is presented below in the list of scrum ceremonies.
One thing to note is that once a sprint has started, you should not change the list of committed stories in the sprint backlog. It is the scrum master’s responsibility to protect the sprint from outside changes and avoid feature creep to ensure a successful sprint release.
Outside of the actual coding and testing work, there are some lightweight meetings to empower self-driving teams and drive agile development. All these ceremonies require the entire scrum team to attend: developers, scrum master, product owner. Remember that just doing these ceremonies on a project does not automatically make you agile. With that said, let’s take a deeper look at the ceremonies that occur within a sprint.
When: At the beginning of the sprint.
Suggested duration of meeting: 1-2 hours, depending on sprint duration.
Purpose: The kick-off meeting before a sprint begins. The product owner will bring a prioritized product backlog filled with tasks that need to be completed, and the group collectively creates a sprint backlog filled with the tasks committed to be done in the sprint.
When: Once every day. Some teams prefer morning standup, some before lunch, and some in the afternoon before leaving work.
Suggested duration of meeting: 15 minutes max. Stand during the meeting to keep it brief.
Purpose: A brief 2-minute update per team member to the whole team on the sprint progress.
More simply, you need to answer the following three questions:
- What did I do since last meeting?
- What will I work on today?
- Is there anything blocking me?
Story Time/Backlog Grooming
When: One regular meeting during a sprint.
Suggested duration of meeting: 1-2 hours.
Purpose: A meeting to go through the prioritized product backlog and start breaking down tasks into smaller, sprint-ready stories that can be taken during sprint planning. These stories have story points assigned to them to show how complex the task is required. The product owner is in charge of leading this meeting.
When: End of the sprint
Suggested duration of meeting: 1 hour
Purpose: As part of the agile ethos, it is important for a fast-moving team to continuously get feedback. This meeting is a time where the team can reflect on:
- What went well during the sprint.
- What didn’t go so well during the sprint.
- One thing to improve for next sprint.
When: End of the sprint
Suggested duration of meeting: 30-60 minutes
Purpose: This is where the team can demo their work that was created over the last sprint. Sometimes external stakeholders can be invited to see the progress of the work. This meeting also allows immediate feedback to go back to the team from stakeholders.
Dual-track agile sprints
In reality, not all teams and sprints go as perfectly as outlined above. Sometimes the product managers in the team work at different schedules compared to the engineers. Backlog items sometimes are poorly defined and not well understood. Specifically, you want to validate ideas as fast as possible, and yet want to take enough time to build a solid product. Although it is important for the different roles to closely communicate with one another, it is not always the case that you need to have the same sprint duration and cycle.
Enter dual-track agile sprints, where you can have a separate discovery track and delivery track. This is where engineers can have 2-4 week development cycles and product managers have 1-2 week sprints to properly discover and explore customer issues and undergo usability testing. This collaborative way of running a sprint allows both product managers and engineers go about their work without the process becoming a hindrance.