Agile is a base philosophy for a wide spectrum of different software development methodologies, including Scrum, Kanban, Lean, and XP. We’ve already covered the main characteristics of Agile software development and this time we’ll talk about Scrum in more detail as currently it’s the most popular approach to implementing Agile methodology.
Scrum is an iterative software development and product management method that applies Agile principles. According to it, the project development is handled in short iterations to allow for business and engineering flexibility. The main idea behind Scrum and, ultimately, Agile is to continuously deliver value to customers.
It’s reflected both in terms of how a given project is managed and what kind of mindset the team members have. If you look closer, Scrum is mostly used for long-term complex projects that require business and engineering flexibility.
In this article, we’ll give a brief breakdown of Scrum components and provide you with a set of best practices that help you make your Scrum better.
Scrum management in a nutshell
Iterative development
The basic Scrum principle is iterative development. The entire project timeline is broken down into short iterations called sprints. During each sprint – each usually lasting two weeks - a team commits to deliver on a set of user stories, concise product feature descriptions. Short iterations ensure that the team prioritizes the features that are actually needed and can be adjusted after receiving feedback. In the best-case scenario, each sprint delivers a small product increment that functions, is QA-approved, and can be handed to stakeholders or end users to get their opinions.
The entire cycle repeats itself every 1-4 weeks
Scrum team and roles
All work must be done by a dedicated Scrum team. A traditional team consists of three main roles:
Scrum master. This person makes sure that the team aligns its actions with Scrum principles, helps reconcile members, and resolve conflicts. Sometimes, a Scrum master contributes to the end sprint goals.
Product owner. This person takes the responsibilities of the product manager. He or she represents the end customer and other stakeholders communicating the overall vision of the product.
Scrum team. The team must be cross-functional, self-organizing, and well… agile. For these reasons, the number of team members mustn’t exceed seven people.
Scrum artifacts
Artifacts are development documents created by the team during development and there are three main ones.
Product backlog. The product backlog contains various requirements documented as user stories or other formats. The document is the main source of requirements and is constantly updated with new items.
Sprint backlog. The sprint backlog contains requirement items that the team committed to complete during a given sprint. As you’ve guessed, sprint backlog items are sourced from the product backlog.
Sprint burndown chart. This is the main tracking document that illustrates how many items were planned per day and how many of them were actually completed. The chart allows team members to forecast their results as compared to initial schedule estimates.
Scrum meetings
Recognizing that the team knows better how to solve the arising problems, Scrum methodology doesn’t impose many rules. So, the logic and goals of Scrum meetings align with the desired outcome rather than the methodology guidelines. There is, however, a traditional set of meetings.
Planning. A planning meeting at the beginning of each sprint is held to decide how many user story (or other requirement) items the team commits to. The average duration of sprint planning is four hours and the whole team must participate. The purpose of this meeting is to take the top items from the backlog and estimate them. Selected items form a sprint backlog.
Daily meetings. Every day all team members participate in a daily Scrum meeting. The goal of a sprint daily meeting is to discuss what was done yesterday and what’s planned to be done today. Daily scrums synchronize the work of the team and maintain the work pace.
Grooming. A grooming meeting is held one or two times a week to remove the items that are no longer needed in the backlog, add new items if necessary, add or remove some of the acceptance criteria, prioritize, and specify estimates.
Sprint demo. The meeting happens at the end of each sprint. The team shows what they’ve produced during the past sprint to stakeholders.
Retrospective. And this last type is also set at the end of the sprint. The retrospective goal is to discuss what went wrong and what went well during the sprint to better align the project progression with goals.
So, let’s discuss the main recommendations to successfully run Scrum in your team. We’ve grouped our recommendations to five categories. We acknowledge that this division is largely conditional as recommendations and their groups intersect each other. For instance, meetings overlap with planning activities. However, the purpose of this division is to simplify your navigation.
Teamwork and meetings
1. Set workshops with stakeholders to form product backlog and product vision
The product backlog is one of the most important artifacts used in Scrum. Basically, it documents the stakeholders' product vision. A good practice is to fill in the product backlog together with stakeholders. This can happen even prior to signing a contract. During product backlog negotiations the team gets to know a stakeholder better as they together align their vision and arrive at mutual understanding of the future product.
2. Invite stakeholders to some Scrum meetings
Stakeholders and/or product owners should participate in some of the Scrum meetings organized by the team. This allows stakeholders to fully experience how the meetings are held and understand how the team communicates from the inside. For instance, stakeholders can assess sprint planning techniques and hear the discussions about the results of work during sprint reviews or demos. The team may receive valuable feedback about the deliverables and collaboration efforts.
3. Don’t break existing teams
If the team has been working for a long time on previous projects, it wouldn’t be the best idea to regroup them for a new project. These people have learned to collaborate and know each other’s velocities. The best practice is to keep them together no matter what. Unfortunately, different skill sets that different projects require don’t allow following this rule all the time.
4. Don’t neglect team building
Team-building activities are important all by themselves. But their value rises dramatically if you have to assemble a team for a new project from the ground up. Team building doesn’t end on informal hanging-outs and Scrum games, which are important. There are effective team-building techniques that revolve around purely professional activities, ranging from sharing skills to adopting engineering practices that foster collaboration.
A standard path of any team building is:
Forming and clarifying roles and processes → Setting decision-making workflow → Optimizing established relationships → Successfully performing and achieving results.
5. Practice stand-ups, literally
Daily meetings are sometimes called stand-ups as everyone should participate standing, unless they are physically unable to do so. The core idea of such an approach is to keep the meeting short. Any meeting may run for hours when everyone is sitting comfortably and talking. As a result, such meetings usually take more time than needed. With stand-up meetings, when everybody stands and talks, it inevitably takes less time.
6. Set communication guidelines when working with remote teams
Communication is hard. Remote communication is even harder: Many important details may be missed in a Skype call and Slack messaging histories. To simplify things, try to work out communication guidelines that will ensure that remote team members efficiently share critical information. For instance, make it obligatory to notify all team members that some user stories were affected by a new issue. Also, you may announce when the issue was fixed or require sharing info about new blockers as soon as they are revealed. If you use specific collaboration software (discussed in point 21), you can set up notification messages and emails that will inform about new issues.
Planning and estimates
7. Estimate together with stakeholder
Estimate the product backlog items in the presence of a stakeholder. First, the team can directly ask all needed questions. Second, the customer hears all discussions and can understand when the estimate is justified and when it’s obviously not. This won’t fully prevent the project from poor estimates, but the format will establish trust and help reduce the chance of further conflicts around estimates.
8. Plan new sprint when product backlog has enough items
Sprint planning must happen only once the product backlog has enough items for at least two sprints. Otherwise, the project could suffer from a scope creep, an uncontrolled growth in a project scope because the scope for the nearest sprints wasn’t fully defined in the product backlog.
9. Set the main goal for each sprint
Sprint goals help make sure that the team and the customer align their objectives. The goals determine what the team must accomplish during the sprint and helps prioritize the items from a backlog. Usually, a product owner sets up a sprint goal before selecting items for the next sprint. Then, during the sprint planning, the team chooses the items for that sprint, according to the goal. The goals are articulated in clear one or two sentence statements like: Implement the check-out workflow: view the cart, set payment, choose delivery method, pay, receive confirmation email.
10. Use Planning Poker to make better estimates
Planning Poker is an agile technique for estimating and planning based on the consensus approach. The rules are simple:
a. A product owner or a customer reads user stories or describes features to estimators.
b. Each estimator receives the cards with number values like 0, 1, 2, 3, 5, 8, 13, 20. These values represent the number of units in which the team estimates (e.g. hours).
c. The estimators discuss the features and then select cards that represent their estimates holding them with backs tuned up.
d. All cards are revealed at the same time. If all estimators selected the same value, it becomes the estimate.
e. If not, the estimators discuss the estimates they give. The highest and the lowest estimators explain their opinions. After that, all estimators reselect estimate cards again. This process is repeated until the consensus is achieved.
This technique is an effective way to achieve more accurate and balanced estimates. To learn more, check our post dedicated to estimating with story points.
Cards for Planning Poker may include some other nuances depending on the type of deck. Image source: grow.org.ua
11. Plan 6-hour day to mitigate risks
Many risks can develop along the sprint progression. For instance, someone from a team can unexpectedly be absent. A good practice to handle absences is to plan six-hour days leaving the remaining two hours each day for risk mitigation. Another way is to plan for a particular percentage of the team to be absent.
12. Don’t stretch sprint time
Sometimes stories are unexpectedly big or too many stories are worked on in parallel and there’s a temptation to stretch a sprint a little bit to complete those and meet the goal. Sacrificing a set rhythm won’t only damage your schedules, it may set a harmful practice of constantly neglecting agreed timeframes. The problems with timing must be discussed during a retrospective meeting.
13. Don’t cut sprint time
On the flip side, it’s also a bad idea to cut the duration of a sprint once all the stories are completed. If you stumble upon such situation it’s better to come up with some small stories and add them to the scope until you hit the sprint ending. This will also help maintain the rhythm.
Managing backlogs
14. Always separate product backlog and sprint backlog
A sprint backlog is frozen in most cases, while product backlog is constantly updated. Keeping these documents separate will ensure that you can plan, efficiently estimate, and forecast your sprints. For instance, by comparing spring backlogs you can measure your team velocity and make more precise estimates in the future.
15. Use task prioritization techniques in product backlog
There are multiple backlog prioritization techniques. While some teams rely on HiPPO (Highest-paid person’s opinion), this doesn’t provide enough transparency for team members and can prevent data-driven decision making. So, let’s discuss the most common ones.
MoSCoW. This clever acronym stands for Must haves, Should haves, Could haves, Won’t haves, four main categories to break down your stories by priority. MoSCoW is the widest and simplest approach to prioritization, yet it doesn’t consider product specifics.
Business value. This approach gives reins to a stakeholder or a product owner who can estimate which user stories will bring the most financial value when realized. This approach is highly efficient if you have a validated business idea.
Technology risks. You can prioritize by the estimated amount of risk for a given feature implementation. This entails implementing the riskiest features first and then approach the project ending sprints with fully predictable engineering tasks. Similar to the previous one, this approach considers that you have a validated business idea or even a working product under update and just need perfect tech implementation.
Kano model. The model is based on customer preferences classified into five categories from the most to the least prioritized ones:
- must-be;
- one-dimensional quality: Users are satisfied if this feature is present and are dissatisfied if not (e.g. many messaging platforms have voice messages, and users expect it);
- attractive quality: Users are happy if the feature is present but won’t be dissatisfied if not (Animoji are cool but not necessary.);
- indifferent quality: Users won’t consider a feature either good, or bad; and
- reverse quality: Users (or some of their groups) are outright dissatisfied with a feature.
Consider this approach if you enter a saturated market and have many competitors.
Walking skeleton. Prioritized features are just enough for the product to be launched as soon as possible. The concept of a walking skeleton is described in detail in our article about building MVPs (minimum viable products). MVP is the most common use case for it.
Validated learning. The features that have the highest market risk are released first to get the feedback early. This approach is efficient if you aim at disrupting the market.
You can use simple Excel documents to form backlogs and prioritize features in it. Image source: Techno-pm.com
16. Assign IDs to items
A simple, yet very important recommendation is to always assign IDs to your user stories or other items in your backlog. This will drastically simplify in-team communication as it’s always better to name a number than share the user story itself.
17. Visualize dependencies to capture bottlenecks
First, you have to divide all dependencies into two groups: 1) functional dependencies and 2) technical dependencies. Stakeholders and product owners have to define functional dependencies, i.e. those that consider the market behavior of the product. (e.g. We can’t implement landing pages before a check-out workflow). Engineers must define technical dependencies (e.g. We must integrate payment gateways prior to engineering a shipping set-up workflow).
Dependencies mapped considering business value and timeframes. Image source: scrum.org
Once dependencies are mapped, you can find bottlenecks and either reconsider their structure or de-prioritize some of them at all.
18. Use Scrum board
A useful technique to enable better sprint visibility is to use a Scrum board. The board itself is divided into four main columns and a couple of optional ones.
Stories. User stories go to the very left column, sourced from the sprint backlog.
Not started. Here, you put specific tasks that have to be covered to implement a respective user story.
In progress. You guessed it. The column contains tasks that are being processed now.
Done. Again, pretty obvious.
Blockers (optional). You may put blocking issues that prevent some tasks to be completed. This would mean that you have to deal with blockers first.
Testing (optional). Depending on your project specific, you may want to add testing tasks into a pipeline.
Product owner’s review (optional). If you need to constantly keep track of product owner’s assessment of the work done, it’s worth adding the review column.
Your board can be both physical and digital. Image source: medium.com/@sashabondareva
While some professionals suggest using only analog versions, you’re free to pick either. If you use JIRA, for instance, the tool for a Scrum board goes out-of-the-box. Similarly, you can use Trello.
Tracking and predicting
19. Visualize sprint burndown
A good practice in Scrum is to use the burndown charts that show the sprint progress. A chart shows the completed items per day against the planned rate of completion. Its main value is to ensure that the sprint progresses according to schedule. This technique helps detect any issues as soon as they appear; so that they can be discussed during daily stand-ups and focus on resolving them early to keep up with the pace.
This chart shows that the team couldn’t complete planned tasks during days five and six, but they were back on track on the seventh and eighth days
20. Use release burndown chart
Similar to sprint burndown, a release burndown chart helps estimate how many sprints are needed to complete a project on schedule and whether the team must adjust the estimated timeframe. The x-axis shows sprints, while y-axis describe how many stories must be completed before the final release. Release burndown is very important if the initial product backlog was updated with new stories along the development course. These updates inevitably impact the release date.
Positive values on the y-axis showcase the initial number of stories while the negative values depict the stories that were added later on
The release burndown chart will provide a real-time visibility on the release date and allow for estimating the number of sprints.
21. Use velocity measurements
Velocity is a measurement that considers how many stories are completed during each sprint compared to initial estimates.
The example illustrates showcases that the commitment unrealistically grew during the second and third sprints, which then allowed the team to reconsider it, aligning with the actual user stories and matching predictions
Velocity measurements are needed to better forecast team commitment and eventual results to reveal estimation problems in the longer run. Usually, 3-5 sprints are enough to gauge general team velocity and then plan sprints according to it. If you still have highly variable results after 5 sprints, it’s worth reconsidering story planning: Your stories must be uneven in size which makes sprint planning unreliable.
22. Leverage quality collaboration software
While you can use Excel spreadsheets for all these measurements, it’s better to stick with versatile tools that are specifically build for Scrum (and ultimately Agile) teams. Here are the most essential ones that you must consider:
JIRA. Perhaps, JIRA is the most popular software development tool among project management professionals. It’s versatile enough, includes all metrics described above, and more. However, you will have to invest 2-4 weeks for your teams to fully transition to JIRA and learn all its merits. The transitional period won’t be fast.
JIRA alternatives. If JIRA is a tank and you need a bike, consider some simpler alternatives. For instance, TeamGantt is simple enough to run basic project planning with Gantt diagrams. The product considers team roles, allows for mapping dependencies and organizing tasks in groups.
Toggl. Toggl is a popular time-tracking tool that won’t substitute JIRA but will be highly supportive. They can also be integrated.
Git. This is an important instrument tool for version control and managing small to large engineering projects.
Slack. Slack is arguably better for team collaboration than other professional and mass messaging platforms. Anyway, you can’t skip considering it. On top of that, if you already use JIRA, Slack integrates with it.
Engineering and quality assurance
23. Don’t separate testing and development
According to Agile principles, developers and QA specialists must work together on features. This will motivate them to collaborate as a team. Engineers will be aware of QA standards while testers will have enough visibility on the engineering progression to proactively suggest quality assurance procedures.
24. Address bug debt in the following sprint
To maintain commitment consistency and stable work rhythm, all bugs found during a current sprint must be resolved in the following sprint. Don’t try to squeeze the fixes into a current sprint, unless they don’t break the initial commitment. This will make your sprint planning more precise and all tracking predictable.
25. Implement continuous integration
Continuous integration (CI) is a technique that entails running automated tests for every feature after an engineer commits it. If the feature gets validated by the test, it’s automatically included into the build which is updated several times a day. As a result, all bugs are found much faster and the engineering team gets timely updates on integration issues. Read more about continuous integration in our separate piece.
Sometimes, continuous integration functions as a part of continuous delivery (CD) – deploying all features as soon as they are committed rather than making a build per sprint. While both CD and CI are frequently adopted for extreme programming (XP) (check our story on this Agile method too), they can be applied in Scrum as well.
Things we missed, but you shouldn’t
This is just a shortlist of best Scrum practices and recommendations that we consider important. It’s not exhaustive and it can’t be so, as many Scrum practices that work in one team for a given project would lead to a complete failure in another. And that’s the whole idea of Agile: Be flexible when you can and experiment with different approaches until you find the one that fits you best. For example, some Agile experts consider pair programming a harmful practice because it stretches delivery time by 15-60 percent.
Nonetheless, we recommend checking some additional materials to get a broader picture:
Agile metrics and KPIs. Besides the ones we described here, you can find a set of project and code management metrics that make your Scrum progression really predictable.
Software quality metrics. Dive even deeper into the code quality measurements.
Scrum documentation by Microsoft. This is a great yet extensive pack of materials on Scrum by Microsoft engineers neatly organized as good software documentation. The authors considered different scenarios for different organizations. E.g. transitioning for enterprise-scale project management.
30 books on Scrum. This article won’t be enough to build a basis for you to become a Scrum Master, but these books curated by scrum.org will.
Okay, the next move.
Please provide us feedback on the practices we suggested.
Do they work for you?
Do you have recommendations that we should have had in this list but for some reason we didn’t?
Please share!