amcneil36.github.io

Additional Scrum Recommendations

In this blog post, I’ll include small tidbits of useful information for Scrum. There may be other blog posts that go further in-depth on some of these topics but this at least will provide a high-level overview of many important areas.

Sprint goal

Each sprint should have a sprint goal which is the goal of what you want to accomplish this sprint.

Daily Standup

In the daily standup, you should talk about progress you made towards the sprint goal yesterday, progress you plan to make towards the sprint goal today, and anything that is blocking you from helping accomplish the sprint goal. Any work that you did that was not part of the sprint goal does not need to be mentioned at the daily standup.

Sprint planning

Use a pull system where team members get to decide which tasks to sign up for.

Leave most of the tasks in sprint planning unassigned. Since some tasks may take longer or shorter than predicted, we want for anyone to be able to pick up tasks as needed.

Product Backlog

The product backlog needs to be sorted by priority with the highest priority items on the top. This way the team can primarily just look at the top of the backlog to see which work is about to be worked on.

The further down the product backlog, the less sense it makes to break down the product backlog item (PBI). This is because when the PBI is farther away from being worked on, there is more time that will pass by until the PBI will be worked on at which point the market could change, the customer could change their mind, or some earlier PBI’s that this PBI depends on got coded up in a different way which changes how this PBI needs to be done. So trying to break down a PBI that is farther out could result in a lot of your time going to waste.

We should have one backlog for each product so it is easy to see which work we should work on at any point of time.

Demos

Team members should spend no more than 2 hours each sprint preparing for the demos. Demos are intentionally held informally to make sure that team members have more time to work on the tasks that they pulled into the sprint.

Team members should only demo user stories that satisfy the team’s definition of done. This should be some sort of end to end functionality where the team members can start the application and show something of value to customers. Some teams will attempt to demo some partially complete functionality where they kick off some test from the back-end. Or maybe they demo the design. Don’t do this. Only demo completed end to end functionality that can be expressed in terms of business value and can be functionally understood by customers.

Retros

Talk about what went well and what can be improved. Try to tackle at least one improvement action each sprint provided that at least one improvement action was mentioned in the retro. Have someone volunteer to be responsible for seeing this improvement action go through.

It is generally a good idea for managers to step out of the retro so that team members can feel more comfortable communicating their recommendations.

Sprint length

Sprints are generally 2-4 weeks in length. I tend to prefer the 2 week sprint the most. That is also the most common sprint length that teams go with. The longer the sprint is, the harder it is to come up with sprint plans that are likely to hold up.

Let the product owner prioritize work

In traditional environments, a manager would choose which work to do. In Scrum, it is the product owner who chooses which work should be done. The product owner will have a business background as well as domain knowledge and understanding of the customers so that he or she can determine which work needs to be done in which order.

Development teams should typically have around 5-7 team members. Too few people results in not much room for specialization and too many people results in stepping on each other’s toes.

A lot of people like Monday - Friday sprints because they are easy to visualize. The only downside of that is that sprints have the planning at the start of the sprint and the demos/reviews at the end of the sprint. Mondays and Fridays are the days where people are more likely to be on vacation since they are near the weekend. As a result, I personally like the Wednesday to Wednesday sprints.

Sources

  1. Rubin, Kenneth. Essential Scrum: A Practical Guide To The Most Popular Agile Process. Addison-Wesley, 2013.
  2. Cohn, Mike. Succeeding With Agile: Software Development Using Scrum. Addison-Wesley, 2013.
  3. Derby, Esther and Larsen, Diana. Agile Retrospectives: Making Good Teams Great. The Pragmatic Programmers, 2006.