Definitive guide to Scrum Sprint

Scrum.

A framework that came into existence in the early 1990s and has got nearly every software team adopting it. The below image alone should give you a good idea of how it is gaining popularity among software development teams.

Apart from the obvious value it provides — shipping quality software, faster — scrum also plays a pivotal role in building relationships with customers. It ensures you’re building features and functionalities your customers really need.

In a time when building a quality product isn’t only important, but table-stakes, perfecting and running an effective sprint can prove to be the difference between products that customers love and products that are rarely used.

And this guide is all about helping you run the perfect sprint as a scrum team, so you can streamline your development process and ship quality software every time.

But first, let's brush up on the basics.

The relationship between product backlog, sprint backlog, a sprint, and a scrum team.

The product backlog and the sprint backlog are two of the three scrum artifacts that plays an important role in implementing an effective Sprint. Let's look at them in detail.

What’s a Product Backlog?

The product backlog is a list of everything from features, enhancements, user requirements, and bug fixes needed to build a complete product.

A product backlog is never complete and is always evolving as you and your team gather new information about your user’s needs and your product’s market.

What’s a Sprint Backlog?

A sprint backlog is a list of prioritized items that are derived from the product backlog. It’s decided collaboratively by the scrum team and will be the set of items that the team will work on during the sprint.

The sprint backlog is usually in the form of user stories, tasks, bugs, and enhancements.

What’s a Sprint?

In Scrum, a Sprint is a collection of items (sprint backlog) that is time-boxed to a month or less to ship a usable, incremental version of the product.

These are the items the scrum team will work on during the sprint duration and deliver at the end of the sprint.

What are the different roles in a Scrum Team?

When a company decides to use Scrum, one of the first things to understand is how Scrum roles differ from traditional project management roles. While there are only three main roles in Scrum, they don’t automatically align with titles familiar to most of us.

1. The Development Team

The development team is a cross-functional team of developers, QA testers, designers, and other technical members who are needed in the actual development of the product.

2. Product Owner

The product owner owns the backlog, strives to prioritize, and takes all the key decisions concerning the product. This person turns all the user chunks of work so the development team can work on them.

3. Scrum Master

The scrum master is responsible for making sure the entire team has everything they need to build and ship a task or user story on time. This person often communicates progress and ensures there aren’t any roadblocks.

How to run an effective Scrum Sprint? The complete Sprint Cycle explained

According to the scrum guide, scrum is lightweight, simple to understand, but difficult to master.

That’s because to run an effective scrum sprint, you need to get multiple aspects right, collaborate cross-functionally, and make sure the tools you use also enable everyone across functions to do their work efficiently.

That means, you’ll have to follow specific principles and steps before, during, and after the sprint, for you to get maximum value from it.

You might be interested in this practical guide to implement scrum values in your team.

A. Before the sprint begins

To run an effective scrum sprint, it isn’t enough to get your team together and start checking off user stories and tasks. You need to lay the ground-work and set the stage. That way, when your team begins executing them, they’ll have all the context they need to deliver quality software on time.

Let’s look at each step separately.

1. Refine the product backlog

As a product owner, you have a certain level of context that others in the team don’t. And product backlog refinement is your chance to fill in those gaps, so when it comes down to executing them, your team will have all the context they need.
Product backlog refinement is all about making sure the items at the top of the backlog are ready for the next sprint. This includes, making sure the user stories are up-to-date, adding acceptance criteria as descriptions to user stories, removing duplicate items, and adjusting priorities based on customer needs.

That’s a lot, right?

Which is why the product owner and the scrum master collaborates to refine and make sure everything is updated. As a rule of thumb, the scrum master and the product owner have enough items updated to plan two sprints. That way, they get the context of what the sprint is building towards — ideally, towards hitting your roadmap goals.

2. Come up with sprint objective based on the product roadmap

With the context of the product roadmap and the user stories updated, the product owner now comes up with the objective the team should aim towards during the sprint.

Your objective should be a conscious decision birthed by the problems your customers have with product goals in mind.

A lot of teams confuse this step with the sprint goal. However, the sprint goal is determined collaboratively by the scrum team during the sprint planning meeting.

3. Run the sprint planning meeting

A sprint planning meeting is where the entire scrum team comes together to discuss and agree on what they’ll deliver in the upcoming sprint.

At the end of the sprint planning meeting, the team should walk away with two things: a sprint goal and a sprint backlog, both of which are decided collaboratively by the entire team.

During the meeting, the product owner brings their perspective and shares with the team the objective for the sprint, why they came up with it, and explains the user stories. This, along with the description inside each user story that the product owner added during refinement gives the development team context to ask questions and estimate them.

Estimation has always been a tricky affair. Estimate too high, you risk getting lethargic in your efforts. Estimate too low, you risk shipping a buggy software in an attempt to ship on time. Finding the sweet spot has been one of the oft-discussed topics in the realm of software development. And anyone who has spent even a few months building software will recommend you break down each user story into smaller chunks of work. Just like we did.

Once your development team has estimated and added story points to all the stories, it’s time to come up with a sprint goal and a sprint backlog that your team will work towards achieving. This depends on the sprint duration and the estimates your team added to each of the user stories. Ideally, a sprint duration is a month or less. However, most teams decide to run a two-week sprint to stay nimble.

And since meetings can go on and on and on, it’s important to time box your sprint planning meeting to no more than 8 hours for a one month sprint. That means, if you decide to have a 2-week sprint, your sprint planning meeting shouldn’t take more than 4 hours.

B. During the sprint

The stage is set. You prioritized user stories, defined the sprint goal, and came up with the sprint backlog. It’s time to finally let the best of your scrum team roll up their sleeves and run to achieve the sprint goal.

Your Design team builds mockups and high fidelity prototypes and passes it to the development team.

The Development team lays the foundation for the feature on the back-end while the front-end developer turns InVision mocks into code.

The QA team tests functionalities as user stories get completed and file bugs for the team to keep track.

Making sure all this information is communicated efficiently and keeping an eye on things so everything gets completed on time is a huge pain.

The unseen friction caused by inefficient processes births a gaping difference between the feature you want at the end of the sprint and the feature that’s actually delivered.

So, how do you remove these inefficiencies from your sprint development process?

Let’s unpack each step one-by-one.

1. Run daily scrum standup meetings every day

A daily scrum meeting is where the development team comes together to share with the rest of the scrum team on what they’re working on, what they will be working on, and share if they’re facing any roadblocks.

The daily scrum meeting is time-boxed to 15 minutes and is held on every day during the sprint.

During the daily scrum standup meeting:

1. The development team take turns to answer three questions:  
   
   - What did I do yesterday that helped the Development Team meet the Sprint Goal?
   
   - What will I do today to help the Development Team meet the Sprint Goal?  
   
   - Do I see any roadblocks that prevent me or the Development Team from meeting the Sprint Goal?
2. The scrum master acts as the facilitator during the meeting, helps remove roadblocks, and ensures the daily scrum meeting is complete in 15 minutes or less.
3. The product owner plays no part in the daily scrum meeting, but attending it gives them the ground-level context of what’s happening.

From an individual standpoint, it’s essential to walk into the day’s daily scrum knowing what you’re going to say. It helps keep the team motivated and keeps the daily scrum meeting going past the 15 minute period.

2. Collaborate cross-functionally

Collaboration is critical to being agile and running an effective sprint as a scrum team. But cross-functional collaboration is even more important.

To build and ship quality software business people and the developers need to consistently communicate and keep the feedback cycle going. This helps to validate and make course corrections effortlessly. This is why the product owner, even if they aren’t actively participating in the daily scrum, need to be present.

3. Manage roadblocks and risks

The daily scrum meeting provides the chance for the team to communicate roadblocks they’re facing.

Often, this is rarely communicated by the team and ends up becoming a giant issue down the road. While it is the scrum master’s role to remove roadblocks, it is up to the development team to bring it up during the meeting.

Until the scrum team is habitual to communicating obstacles, it can be a good practice to consistently remind and ask the team to bring up potential issues.
As you can imagine, asking if anyone in the team is facing any issues with completing their task every day helps build a healthy habit of communicating early. This can help the team uncover risks early and avoid the sprint from getting delayed or not achieving its goal.

Another great way to see if your team is having a roadblock is to keep an eye on the burndown or burnup report. If your burndown report looks like the below image at the end of the sprint, it means your team doesn't update progress regularly. This could be due to difficulty in using the tool or they might've hit a roadblock and need help. When this happens, it can result in the product owner being left in the dark and ultimately lead to a missed deadline.

For something as critical as a sprint where you’re working together to complete functionality on time, it then becomes important to support the kind of flexibility the development teams seek.

And by giving you a single, dedicated view for your sprint, you can quickly view your sprint backlog, access scrum boards, view burnup or burndown charts, and get a complete overview of the sprint.

C. Towards the end of the sprint — it’s showtime!

1. Run sprint review meeting

There’s nothing more satisfying than moving the item you worked on from “In code review” to “Done”. But to cross the line and complete the work requires good planning. This is where the acceptance criteria you came up with during the sprint planning meeting will help you.

Once all items are moved to the “Done” state, the entire scrum team calls for the sprint review meeting and invites other stakeholders such as managers, beta users, or clients. The sprint review meeting is time-boxed to 4 hours for a month-long sprint.

During the meeting, the development team takes the spotlight to show all the work they’ve accomplished during the sprint. This allows all the stakeholders to see the feature, play with it, and ask questions.

This, however, doesn’t mean the purpose of a sprint review meeting is to present your work. It is to collect feedback so you can make improvements in future sprints. That’s why, for whatever reasons your team may want to skip the sprint review meeting, you shouldn’t.

Because if you don’t know how your beta customers, clients, or even your managers perceive your new functionalities, how can you improve it in the future sprints?

2. Run sprint retrospective meeting and talk about areas you can improve

Like sprint review meetings, the sprint retrospective meetings are also often skipped. And that only creates more headaches down the line.

Think of it like this: if you just had a nice meal at a restaurant known for its awesome desserts, and the waitress did not suggest that creamy Tiramisu to you, she’d actually be doing you a terrible disservice.

It’s the same with your sprint retrospectives. If you aren’t looking back to identify areas for improvement, you’re doing a disservice to both your team and your customers! After all, the agile manifesto makes it clear: To best live the agile values, teams should meet regularly to check-in and make adjustments.

The sprint retrospective meeting is designed exactly for that.

The sprint retrospective meeting is where the scrum master and the development team get together to look back at the sprint, inspect itself, and identify areas for improvements that can be used for future sprints.

Sprint retrospective meetings are time-boxed to 3 hours for a 1-month sprint and are held after the sprint review but before the beginning of the next sprint planning meeting. That way, the team can incorporate these suggestions into the next sprint.

This meeting can easily be turned into something where people start pointing fingers. Which is why it’s best to be mindful and communicate by starting each sentence with:

1. I like…
2. I wish…
3. What if?

This keeps the tone of the meeting positive and encourages others to improve.

Here's a detailed article with fun sprint retrospective ideas with templates.

What should you look for in a tool that supports scrum sprints?

In product development, the definition of success is vague. Inefficiencies are invisible. But failures are apparent. Which is why you don’t need just any other agile tool.

Nearly 56% of all product and project managers are on the lookout for a new tool every year. According to Software Advice, the primary reason is that they need a more robust solution (37%).

But what does a robust solution even mean?

You need the ability to track progress at a micro level (task level) and see how it affects the progress at a macro level (feature level).

Let’s look at how this translates to the capabilities you should look for in a scrum project management tool.

Effortless and flexible feature planning

From the moment you create a task till it hits production, ‘change’ will forever be a constant in the development of the feature. New user stories will get added, unexpected bugs creep up, and your customers will want functional improvements.
To handle this constant change in requirements, simply creating tickets that sit in isolation isn’t enough. You need a way to plan features with the bigger context of what changed and how it affects the feature as a whole.

Here are some questions to keep in mind:

• Are you spending more time managing the tool than planning your feature?- Will you be able to add a new task/user story/enhancement/bug at the speed of thought instead of waiting for multiple page loads?
• Can you see the bigger context of how adding a new item fits into the context of the entire feature?

Here’s a look at the feature-set you want to see in a scrum software project management tool when running sprints.

• Simple document like interface to effortlessly plan features
• Effortless keyboard shortcuts to quickly create new items
• Ability to create sections and group similar items together

Seamless cross functional collaboration

Most tools are built purposefully for development teams but alienate the rest. And setting up multiple configurations to accommodate other members has historically only slowed teams down.

With a scrum team on most occasions being a cross-functional team, how do you collaborate across functions when your tool makes it exponentially hard for other members to work?

Here are some questions to keep in mind:

• Does your team have to go through a steep learning curve?
• Can members of a cross-functional team come together and handoff work effortlessly?

Here’s how this should translate into features in your sprint tool:

• The ability to add scrum boards for each function — dev, design, QA, etc. — so you can track progress in each team and they can work from their world view of the sprint without losing context.
• The ability to quickly move an item from one board to another. For example, from Design - Done to Dev - Todo.

Gain complete visibility into the Sprint’s progress

Checking off user stories from your Sprint is great. But you still need to track the sprint’s progress as a whole. You need to see how many estimation points are remaining, what percentage of the sprint is completed, and when needed, manage workload using a Scrum Board.

Here are few questions you should ask yourself while evaluating a scrum software tool:

• Do you get a dedicated view for tracking Sprints? Or should you duct-tape your tool and setup configurations to run and track a sprint?
• Can you track each item in the sprint backlog?
• Are you able to track effortlessly on how much work is pending in the Sprint? Ideally, you should be able to track this by number of items, estimation points, or by percentage.
• Does the tool allow you to quickly navigate to track progress using reports?

Features you should look for in a scrum software:

• A dedicated view that lets you track the entire sprint.
• The ability to view reports, track a specific item in the sprint, and view the sprint in a scrum board.

Ability to track progress in multiple levels

It isn’t enough if you’re able to track and run a sprint as a scrum team.
You need to be able to zoom in and track a specific user story and see its progress. You should be able to take a step back and track a specific team, so you can manage workloads and complete on time.  

And you need to be able to completely zoom out and see how all these updates across multiple teams affect your entire feature’s progress, so you can update your manager on when the feature will ship.

Some questions to ask yourself when evaluating a scrum tool:

• Do you have to set up multiple configurations?
• Does it provide the capability to track user stories, teams, sprints, and an entire feature?

How does this translate into features in a scrum software tool?

• My tasks to focus on just the items assigned to you
• Ability to create specific workflows for each team to track their progress
• A dedicated view that captures all the updates and shows the progress of the entire feature

Developer friendly

Developers, at the end of the day, are going to build your software. And it is essential to make it easier for them to get onboarded on to the tool quickly, update progress effortlessly, and keep everyone in-sync seamlessly.

Questions to ask yourself when evaluating a developer-friendly scrum software:

• Does the tool have a low or negligible learning curve?
• Can your development team adopt the tool even if they aren’t familiar with agile terminologies?
• Does it tightly integrate with GitHub, Bitbucket, or GitLab?
• Once integrated, can the tool automatically update statuses in the tool based on their activity in the version control system?
• Can your development team quickly create new pull requests from the scrum tool?
• Does the scrum software provide complete information of all the changes the development team made in each commit, branch, or pull request?
• Can developers update everyone on the progress effortlessly?

Some features you should look for in a developer-friendly scrum software tool:

• Tight integration with GitHub, Bitbucket, and GitLab- Ability to set up Git Workflow Automations to automatically update statuses based on developer workflow
• Integration with Slack to update team members
• Developer-friendly public APIs for when you need to customize your process