Practical Advice for the Scrum Framework

This is the second piece in our guest series from Paul Heidema, Partner & Vice President of Training and Development at Berteig Consulting.

Scrum is the most popular of the Agile frameworks. It is also one of the hardest to implement well. Many organizations have used Scrum only to find out that the Scrum framework is simple, yet the implementation is quite difficult. Here are some practical tips to advance your use of Scrum.

The Scrum Alliance wrote a short piece called "The Scrum Framework in 30 Seconds" that I will add tips to.

“A product owner creates a prioritized wish list called a product backlog.” This product backlog is continuously being prioritized or ordered by the Product Owner.

  • Practical advice: This list of work is best prioritized through a combination of two elements: value and effort. Value is determined by the Product Owner and the stakeholders through conversations, research and understanding. Effort is determined by the team, usually through collective consultation and by comparing a single Product Backlog Item (PBI) to the others.

“During sprint planning, the team pulls a small chunk from the top of that wish list, a sprint backlog, and decides how to implement those pieces.” A small chunk is the amount of work that the team believes that it can complete with the Sprint.

  • Practical advice: One of the most effective ways to decide on how much to put into the Sprint Backlog is by using Commitment Velocity which is a historical tracking of how much the team has remaining at the end of each Sprint. Breaking down the Sprint Backlog into tasks is where the team members take action during the Spring Planning Meeting. In this meeting, they try to create every single tasks that is needed to complete a single backlog item, and at the same time knowing that new tasks will be uncovered during the Sprint.

“The team has a certain amount of time — a sprint (usually two to four weeks) — to complete its work, but it meets each day to assess its progress (daily Scrum).” The Sprint length is consistent for the team, be it 1 week, 2 weeks, 3 or 4 weeks.

  • Practical advice: It is best for the team to choose its Sprint length based on the urgency of the work, the patterns that you want to create in your team, the pressure to deliver value soon, and the patience (or lack thereof) by the key stakeholders and customers. The time constraint of a week or two helps the team to do its best work by focusing on delivering value instead of adding “extra” features that are not requested or needed. The Daily Scrum is a meeting that takes place every day of the Sprint and it is used to build unity of vision, unity of thought, and unity of action. Be creative with how you guide the Daily Scrum. For example, you could use a ball as the talking item and then pass the ball to whoever you like when you are done.

“Along the way, the ScrumMaster keeps the team focused on its goal.” The ScrumMaster is a single individual that helps to support and guide the team in its use of Scrum.

  • Practical advice: For the ScrumMaster to help keep the team focused on its goal (the Sprint Backlog), he or she needs to become ever more knowledgeable about Scrum. This can be done through conversations with other practitioners, reading articles and books, attending workshops and training, and even joining groups and forums. It is also valuable to the ScrumMaster to see himself/herself as a servant who is there to support the team- not manage the team.

“At the end of the sprint, the work should be potentially shippable: ready to hand to a customer, put on a store shelf, or show to a stakeholder.” Potentially shippable means that with little to no effort (a few minutes or a few button clicks) the product can be live for the customers to use.

  • Practical advice: This is the consistent goal for all Sprints! This helps to focus the team on building quality in, making user-based decisions, and protecting themselves from wasteful activities. This also promotes the use of great software engineering practices such as pair programming and test driven development which is part of Extreme Programming (another Agile framework).

“The sprint ends with a sprint review and retrospective.” Both of these meetings are attended by the entire team, and the first meeting is open to all.

  • Practical advice: The purpose of the Sprint Review meeting is to share with stakeholders, users, and customers the progress that the team has made. This is best done by a hands-on demonstration of the product where those invited get to “play” with it and give real-time feedback. The purpose of the Sprint Retrospective meeting is for the Scrum team (and only them) to reflect on how the team did in terms of their process, teamwork and the Sprint goal. This second meeting is where the team has a significant amount of time to inspect and adapt. Be creative, be inventive, and find ways to make this meeting safe so that all team members can express and explore together.

“As the next sprint begins, the team chooses another chunk of the product backlog and begins working again.” The cyclical nature of the Sprints and its consistent timeframe help the team to get into a rhythm.

  • There is no break between Sprints so that the team keeps its flow. Having a repetitive structure that is built into Scrum helps to build capacity in the team members and the team as a whole. It also helps the organization that is around the team to learn how to engage with the team. Look for ways to uncover the best Sprint length for the team.

Scrum has three roles, four ceremonies, and three artifacts – which makes it seem easy. However, there are many subtle nuances that each member of the team and those supporting the team need to learn to become effective at Scrum. Start your journey with Scrum today or continue the adventure by trying some of the tips above. Good luck!

Written by

Steph Brown

Steph Brown

Sign up for our newsletter