Scrum Best Practices Guide - Understanding Scrum

Scrum Best Practices Guide - Understanding Scrum
Page content

So far in this series of articles, a multitude of topics has been discussed - including the roles involved in Scrum projects and Scrum environments. What hasn’t been covered is a guide to some of the best practices involved in utilizing the Scrum project management methodology. Best practices are the most effective means by which to execute some task. Below you will find a list of Scrum best practices.

1. Holding Effective Daily Scrum Meetings

In order to have a successful Scrum project, you will need to hold effective daily scrum meetings. Effective daily scrum meetings exhibit the following features:

  • Members stand rather than sit - this helps to keep the meeting short.
  • There are five goals of the daily scrum: to recommit to the project as a team, to comunicate status of the project, to identify any obstacles the team has come across, to set the day’s direction, and to help build the cohesiveness of the team.
  • All project stakeholders should attend the daily scrum.
  • Keep all summaries short - each member should focus only on the following three items: what was done yesterday, what will be done today, what issues may cause problems for progress.
  • The meeting should be held in the same place and at the same time every day.
  • The meeting should be fifteen minutes or less.

By adhering to the above practices during your daily scrum meeting, you can increase the efficiency of your team and improve the quality of your project by avoiding tedious and time-wasting meetings.

2. The Sprint and Product Backlogs

It is important to keep your Sprint Backlog and your Product Backlogs separate, organized, and prioritized. Remember that the Sprint Backlog contains the work you will be working on during the Sprint and nothing else. If other issues come up during a Sprint, then they should be documented on the Product Backlog. Here are some tips for dealing effectively with your Sprint and Product Backlogs:

  • If you’re not already using Excel, look into using it to create your Backlog. This way you can prioritize and reprioritize your tasks quickly and easily.
  • For that matter, you may wish to use one of the many project management software options, like ScrumDesk, to manage your backlogs.
  • Make sure you do not confuse your Sprint Backlog with your Product Backlog. If you wind up putting items on your Sprint Backlog that should be on your Product Backlog, you will wind up putting out fires.
  • Reprioritize your Product Backlog each time you add to it. It will save you trouble in the long-run.
  • Do not add more to your Sprint Backlog than can be reasonably completed during your Sprint. You will only frustrate yourself and your team.
  • Give each item on your backlog an ID number - this way you can keep track of tasks and stories no matter what you call them.
  • Don’t forget to include an estimate of how long it will take to complete the item in your backlog
  • Your Sprint Backlog should center around one, unifying, goal.
  • Make sure to indicate in your Sprint backlog whether someone is currently working on the item (and who it is) and the status of that item
  • Be as specific as possible with each part of your Sprint Backlog story.

By maintaining your Backlogs, you can save time and effort - and you can help maximize productivity by working on only the items that matter to your project.

3. Sprints & Sprint Planning Meetings

In the preceding section, you learned about Sprint Backlog, Product Backlog, and Daily Scrum best practices. Sprints are the focused time period where team members work on the items from the Sprint Backlog. Most sprints run about 30 days. A successful sprint depends upon a successful sprint planning meeting. Here are some tips on sprint planning and sprint best practices:

  • Make sure you come up with a clear goal for your sprint during the planning session. This will help focus your sprint efforts.
  • Come up with a list of highly committed team members for the sprint.
  • Don’t overlook the importance of keeping a Sprint Burndown chart for your Sprint backlog. A sprint burndown, if you recall from the article on Scrum methodology, represents in graphic form what is left to do of the sprint backlog work.
  • Keep the sprint time to thirty days, the average for a sprint. Any longer and you are trying to accomplish too much. Any shorter and you may not have time to complete a demo.
  • Only begin a sprint planning session once your product backlog has enough organization and detail. If you start a sprint planning session when you lack adequate detail, then your project may suffer from scope creep.
  • Once you select the sprint backlog activities, realize that you must commit to them completely.
  • The sprint planning meeting should take no longer and no shorter than four hours.

4. Teams

Finally, Scrum teams can make or break your Scrum project. You should choose a team, not only for each member’s previous sucesses, but also for the ability of the members to cooporate and communiate with one another. Here are some more best Scrum team practices:

  • Most Scrum teams consist of between six and ten people. However, with careful scaling, your Scrum project may consist of one hundred or more people.
  • Spend some time on team-building strategies. By dedicating time to creating a team that works well together, you can help to ensure that your Scrum project will succeed.
  • Teams in Scrum must be able ot self-organize. If a team contains one or two procrastinators, it may be hard for the team to move forward on projects.
  • Facilitate communication among team members by utilizing handy project collaboration software. This ensures that everyone in the team will be on the same page, know what’s going on, and know what needs to be worked on next. It also allows for the testers to have open access to new lines of code in software projects.
  • Most teams will realize that what seemed like “not that much work” is actually a lot of work once a Sprint starts. Be sure that your team members do not assign themselves more than can be reasonably completed with accuracy during a Sprint.
  • If a team member is absent, the team’s work could be seriously hindered, especially if that individual was working on something that has other task dependancies. If a team member knows she will be absent ahead of time, this is the ideal situation since the team members can pick up the slack. If the team member does not know, then this could create a problem. One way to handle absences is to plan six hour days. Another is to only plan for a certain percentage of the team to show up. Whatever you do, make sure you take this contingency into account when planning.

This post is part of the series: Understanding Scrum - Part II

This series of articles details the principals behind Scrum methodologies - the process, environment, process, roles, etc. Everything you need to know to understand Scrum, you will find in these articles.

  1. Understanding Scrum - Sample Product Backlog
  2. Understanding Scrum - Team Roles and Responsibilities
  3. Understanding Scrum - Best Practices Guide