Red Hat ブログ

Planning and executing is about understanding what can be delivered, when, and how to get it done. Previously in this series, we worked through some practices to define our team’s work. In this post, we will talk about determining the level of effort for stories and planning and executing the next sprint/iteration.

### Relative Sizing or Story Pointing

Relative Sizing, or Story Pointing, is a practice where the team determines the level of effort required to complete a given task relative to other tasks in the backlog.

Sizing a story has less to do with how much time the team thinks is necessary to complete the task and more to do with the amount of effort required. Anyone interested can find many articles online that deal with the notoriously bad estimation of software engineers, so I won’t go into too much detail about that here.

While a story should be able to be completed within the span of a single sprint, time is not the sole determination of the level of effort.

There are many different ways to reflect the size (level of effort) of a story, some of which are:

• Simple numbers: 1, 2, 3, 4, 5, 6, ...

• Fibonacci Sequence: 1, 2, 3, 5, 8, 13, ...

• T-Shirt Sizes: XS, S, M, L, XL, …

• Fruits: Grape, Plum, Apple, Orange, …

• Playing Cards: Joker, Ace, Jack/Knave, Queen, King.

What’s important is not the scaling or types of sizes used, but the meaning the sizes represent to the team. The team should discuss the sizes and their meaning so that their use is more easily understood, leading to more efficient and productive backlog grooming and story sizing sessions.

As a final thought on this topic, it is very important that the team considers their “definition of done” when conducting a relative sizing or story pointing exercise. Many teams that were just getting started have found it helpful to have the definition of done displayed alongside the backlog during the first few sizing sessions. Do this, and your estimates of the level of effort will be much more realistic.

The team should not expect its first few sizing sessions to be very accurate, as relative sizing is a skill that must be developed over time. Stick with it, and the accuracy of relative sizing should improve!

### Sprint Planning

Sprint Planning, sometimes referred to as “Iteration Planning,” is a practice where we take the stories we have created and select a subset to be completed throughout the next iteration (sprint).

A sprint or iteration is usually a one or two-week period of time. It is recommended that new teams start with a one-week sprint and ensure they’re confident they can complete the entire subset of work within the time period. Here are a few reasons why:

• Your team is not yet mature enough in its practices to be able to estimate accurately. Even a team of 20-year veteran software engineers who know Agile, Lean, Scrum and Extreme Programming will still be inexperienced working together.

• It takes time for a new team to understand a new product. If you have been following along with this series, you may be on a new team or planning to start one. Your team has a lot of discovery to do before they will have explored every nuance of the product you wish to create. This means that, even if you spend days applying each of the practices in this series, many things are still going to come up that need to be thought about.

• There is no such thing as a perfect plan. We can aspire to have as complete a plan as possible. However, Open Practices, Agile, Lean, and other work methodologies teach us that “perfect plans” are unnecessary to achieve success and productivity. The Agile manifesto alludes to this in its second stanza, “Working software over comprehensive documentation,” and explicitly calls it out in its final stanza, “Responding to change over following a plan.”

Therefore, it is better to “start small.” The team should gradually adjust the length of its sprints and the amount of work it can confidently complete within their sprints over time.

A very simple method of planning the team’s first sprint is:

1. Ensure the backlog is completely “pointed” (See: Relative Sizing) and prioritized with the most crucial stories at the top and less important or not very well understood stories at the bottom.

2. Have everyone in the team take turns selecting one story for which they will be responsible for completing within the one week sprint.

3. Repeat this process until every team member has two stories in the sprint backlog,

4. From the remaining stories, have each team member select one additional story that is “on deck”—one they can be prepared to go into if they have enough time to spare after completing their first two stories.

5. Add up the total number of story points in the sprint backlog, excluding the “on deck” stories. This is the “base case” number of sprint points for the team and will be used in the next sprint planning exercise.

### Planning the next sprint

When the team is ready to plan its second sprint, take the “base case” number of sprint points and compare it to the actual number of story points completed. If the base case is lower, use the actual number of points completed as the new base.

Only put stories adding up to that many points into the second sprint’s backlog. If the actual number is lower than the base case, the second sprint’s points total should not exceed the actual number from the previous sprint. Repeat this process throughout the next few weeks or sprints.

It should be noted that this does create a “yo-yo effect.” That’s okay! We’re accounting for it. The purpose of explicitly causing it, in this case, is so that the team can focus more on discovering its ability to realistically deliver without the demoralizing impact of having stories left incomplete.

Pro Tip: If the team completes four sprints in a row where they have to keep adding stories into the sprint to keep everyone productive and engaged, add 5% to the planned sprint point total and round up in the next sprint planning. That becomes the new target.

Continue doing this over the next few sprints until the team has a sprint where one or more stories cannot be completed in the one-week period of time. Back off the sprint points by 5%, iterate three times, and if over those next three sprints, the team can complete all of its stories on time, use this new number as the base case and stick with it.

At this point (roughly 10-15 weeks), the team members should consider whether they like one-week sprints or if they want to try two-week sprints.

If they choose two-week sprints, double the base case number, then subtract 10% and round down to the next whole number. Continue the exercise from above just as you did with one-week sprints until the team reaches a plateau.

Once the team has reached a plateau over the course of several sprints, it can demonstrably say, “We’re good at estimating as a team,” and it can provide realistic estimates to stakeholders, upper management, other teams, or whomever else is concerned with the team’s output.

### Sprint Execution

Sprint Execution is not a practice per se, but I thought it would be important to provide tips to give your first few and subsequent sprints a higher chance of success.

Up until now, we have kept the practices very simple and very practical. Starting your first sprint can be both exciting and nerve-wracking for even the most prepared and experienced teams. Let’s look at some practical items to consider during sprint execution that may warrant inclusion in the team’s Social Contract.

We all have jobs that require us to wear many different hats (pun intended), and in today’s very connected world, many things come up that seem like they require immediate attention. Do not fall into this trap! When your team has planned a sprint, the work in that sprint is the top priority.

Yes, there are “fires” that come up and require immediate handling, but once the fire is put out and the retrospective conducted on that fire, get back to your sprint stories.

This is very important because, whether we like it or not, a sprint plan promises to deliver features and functionality. Someone somewhere is counting on you and your team to deliver on that promise, and the team will therefore need to ensure sprint work is prioritized accordingly.

Let’s face it, our world is built on distractions. These may be other meetings, ad-hoc tasks, or just day-to-day life. A very easy way to let others know that your time is valuable and that what they want you to work on is not the only thing you have to work on is to block your calendar.

Set up an event or meeting for a few hours at a time for every day you plan to work on stories in the sprint. What’s even better: Name the event after the story and include blocks on your calendar for breaks and lunch. This way, anyone who would normally set up a meeting or engage with you while you’re trying to work can readily see that your time is already dedicated elsewhere.

Sending an email before starting your planned sprint is a good way to keep stakeholder communication efficient and productive—and to keep them from checking in with you every few minutes on the status of your stories. Ideally, this email comes from a team distribution or mailing list account. The content of the email should include:

• The planned sprint start and end dates.

• A summary of the features and functionality being worked on by the team.

• A link to the team’s calendars so they can see the hours being blocked for stories, but also which hours are open should there be a pressing need for a discussion.

• The date and time for the team’s end-of-sprint demo (we’ll talk about this in a later section).

Going further with this idea, if your stakeholders are very invested in the day-to-day progress of the team, designate someone to send an email after your daily stand-up that includes each team member’s updates. To keep it simple, the format for each team member could be:

• Completed Yesterday

• \${THING}

• Completing Today

• \${THING}

• Impediments

• \${THING}

This takes mere minutes to do but pays dividends in keeping the stakeholders informed and the team’s relationship with their stakeholders strong while minimizing interruptions during the sprint.

Another technique instead of daily emails: invite your stakeholders to attend your daily stand-ups so that they can see for themselves how things are progressing and even potentially help address would-be blockers.

The rule for stakeholder attendance should be that they are to wait until the end of the stand-up if they have questions, concerns, or other input so as not to throw off the team during what should be a 10 to a 20-minute meeting (depending on the size of the team).

### Speak up!

This is very important for both productivity and team culture: Speak up if you have a question or are otherwise “stuck.” The sooner a concern is raised, the sooner it can be addressed. This seems very simple and almost doesn’t bear mentioning, but you’d be surprised how often team members will feel that they cannot speak up until it’s too late.

A big part of this is ensuring all team members see the team as a safe place to work and express ideas. This can require quite a bit of work as teams are made up of different people with different reactions to the same turn of phrase. Being conscious of this, getting to know your team outside of the product they’re working on, and making a concerted effort to be open and empathetic are ways to encourage everyone to speak up as needed.

### Conclusion

In this post, we discussed estimating our work via Relative Sizing, planning our iterations via Sprint Planning, and navigating successful Sprint Execution. Applying these practices and suggestions will greatly assist the team in successfully delivering value in an iterative fashion.

In the next article in this series, we will discuss how to showcase the team’s work effectively, as well as how the team can ensure iterative improvement on its journey to deliver value quickly and efficiently.

### Open Practice Library series on the Red Hat Blog

Learn more about our community-driven collection of exercises for making incremental progress along the product delivery cycle from the full Open Practice Library series:

### 執筆者紹介

Brian Tomlinson is a Senior Architect with many years of experience contributing to Linux and FLOSS communities as a user, administrator, and contributor. His work at Red Hat includes delivery of Red Hat Open Transformation, Kubernetes Operators, Container Application Development, and Hybrid Cloud Infrastructure for Red Hat Services customers.