How Big is Too Big for a Scrum Team?

You May Need to Divide Your Project into More than One Scrum Team

In Chapter 1 of the GSD Scrum Handbook, we talk about the size of the GSD Gold scrum team. What is the right number of team members? The Scrum Alliance recommends a scrum team size of no more than 9 members. At GSD Mindset, we also recommend organizing a scrum team with all the skills to complete quality work valued by the customer: Product Owner, Scrum Master, Tech Lead or Architect, Business Analyst (to help Product Owner write Stories), Programmers and Quality Assurance (QA) testers.

A scrum team size of 9 members may be optimal for Scrum, however your project may need a bigger team to complete all the required work on time. In Agile projects as well as Traditional projects, we face the same Time-Scope-Budget triangle constraints. When Time is fixed, sometimes upper management agrees to add Budget, and then your boss goes out and hires more team members.

How Do You Know When the Team is Too Big?

One indicator that helps determine whether or not a scrum team could be too big is the length of standup. If your team sticks to the constructs of standup and they cannot complete the meeting in less than 15 minutes, the scrum team may be too big.

Large scrum teams developing lots of features that cross multiple business boundaries can be another indicator. If you notice scrum team members stop paying attention half way through standup, retrospective or sprint planning, then dividing the team is a good way to speed up those meetings up and keep everyone engaged.

There are lots of reasons why teams get unwieldy and difficult to manage. If you’ve got 10+ team members on the same scrum team and you feel like the team is becoming inefficient, it probably is inefficient.

How Do We Split the Scrum Team?

Identifying the need to split one team into two teams is easy; deciding how to divide the teams is not always easy. We at GSD Mindset believe all the roles listed above are required to form a competent team. We  want you to continue this practice as you plan for and hire new scrum team resources.

When management wants to get more stuff done, their first thought is to hire more programmers. However, if you double the number of programmers without hiring QA testers, QA becomes a bottleneck. If you don’t hire another Business Analyst to help the Product Owner write Stories, grooming and sprint planning can get delayed.

Yes, you can share the same Product Owner, Scrum Master, Tech Lead and Business Analyst across 2 teams that share the same Backlog when you add 2-3 new programmers. We do encourage you to keep the ratio of programmers to QA testers at 3:1 if possible.

Of course, your application may require a different mix of players. The important takeaway here to remember that as your scrum team grows and splits into more scrum teams, keep in mind: The correct mix of team players ensures maximum throughput.

How Many Scrum Teams Can Pull from One Backlog?

Scrum teams with shared Backlogs continue to share the same grooming sessions, sprint planning and retrospectives. Those meetings may still be unwieldy, because you only really divided the development and QA aspect of completing Stories. Consider this before you decide to divide and still share.

I once worked successfully with 3 scrum teams pulling from a shared Backlog. The combined team supported multiple applications and the Engineering Manager wanted all the programmers to have the knowledge to work on any one of them, depending on the needs of the Product Owner. Keeping Stories written and groomed became challenging, so each scrum team added their own Business Analyst to help write Stories. The burden fell on the Product Owner to ensure the right mix of high-priority Stories were ready for sprint planning. Our original scrum team organically grew from 1 to 3 teams over the course of 2 years, with the same Product Owner and Scrum Master, so they were experienced enough to handle a Backlog with hundreds of Stories.

I would not recommend 3 teams sharing 1 Backlog for those new to Scrum.

I would never attempt to manage 4 teams from a shared Backlog.

How Do We Divide the Backlog?

If you divided your functional requirements into independent feature sets or Epics as described in Chapter 2 of the GSD Scrum Handbook and you include Epic as one of your Story attributes in your agile project management tool (like JIRA or VersionOne), then you can easily start a new project and divide the Backlog. If not, then you need to properly attribute your Stories with an Epic.

If you are dividing 1 scrum team into 2 scrum teams, the Product Owner, Business Analyst and Tech Lead should review the Epics and organize them so the 2 sets of Epics have the least amount of overlap. The 2 scrum teams must be organized so they can independently complete their Stories.

After the split:

  • Each scrum team must be able to close Stories without relying on the other scrum team to complete any work
  • Cross-team knowledge sharing is appropriate.
  • Cross-team pair programming is not appropriate.

How Do We Divide the Team?

Agile is about self-managing teams. As tempting as it may be for the Engineering Manager or Product Owner to divide the scrum teams based on tribal knowledge about the Epics in each Backlog, don’t do it! Let the teams divide themselves and pick their own team members.

Organizing for success is not always easy.

Think about what stuff needs to get done and think outside the box.

 

Cynthia Kahn

Cynthia Kahn

 

Cynthia Kahn
CynthiaK@gsd.guru  503.799.5500

read more

A Spike Story Should Get Story Points Too

Assigning Story Points to each Spike Story Improves Epic Planning Accuracy

In Scrum, we have a special type of Story called a Spike. The Product Owner or another team member writes a Spike Story when the team does not understand the requirement well enough to write a Story or architect a solution.

The Spike Story requirement describes what the team needs to learn or test before they can move forward with product development. Since all Stories must add value, the Spike acceptance criteria describes what must be completed or decided to provide closure. 

Example Spike use cases could include:

  • Install and become familiar with a new software tool.
  • Compare and analyze two similar architecture solutions in order to choose one to move forward with.
  • Research a long-standing issue or bug before designing a solution.

Why Write a Spike Story?

Scrum expects that the Development Team knows enough about the Story requirements to size the level of effort in Story Points to deliver the solution within the Sprint. When the team does not understand enough about how to develop the solution, the team acknowledges the fact and writes a Spike Story for the Backlog.

Use the power of the Spike sparingly. A Spike Story is not the same as Analysis and Design, which should be part of the lifecycle of every Story. A Spike Story has an outcome that allows the team to move forward with the real Story. In addition to the learning goal as acceptance criteria, another good practice is to add acceptance criteria that includes writing the successor Story and putting it in the Backlog as candidate for next Sprint.

Why Assign Story Points?

Most who practice Scrum do not assign Story Points to Spike Stories. We at GSD Mindset disagree. The output from a Spike Story is increased team knowledge that leads to better overall solution design. By assigning Story Points to a Spike, you also limit the level of effort expended to close it, so the team doesn’t get lost down some rat hole researching a new tool or attempting to resolve an issue.

It’s About Predictable Velocity for Planning

Energy expended to complete a Spike Story takes away from available energy spent to complete another Story from the Backlog. We at GSD Mindset believe everything brought into a Sprint should have Story Points, so you can better predict the total amount of work the team can complete within the Sprint.

Since Velocity is also used to estimate the length of time required to build an Epic, any background research or creation of small prototypes to try out potential solution architectures should be included in all planning estimates. Assigning Story Points to Spike Stories and including those points in the overall estimate for the Epic helps increase the accuracy of your team’s estimated time to completion.

What are your thoughts? Does your team size Spikes?

 

 

Cynthia Kahn

Cynthia Kahn

 

Cynthia Kahn
CynthiaK@gsd.guru  503.799.5500

read more

Reducing Sprint Velocity may be better for your Scrum Team

Does your Scrum Team need to Buffer Sprint Velocity?

Consistent Sprint Velocity is key to predictable delivery in the real world. If your team’s Sprint Velocity is erratic, it’s hard to determine what to bring into the Sprint Backlog and to meet your Sprint commitments.

Not all scrum teams have the luxury of only working on new development. If your team supports production applications, emergencies may occur that divert the team’s energy. If this happens on a regular basis, it no doubt wreaks havoc on your Burndown. By introducing the concept of a Sprint Buffer, which consciously reduces the number of Story Points brought into the Sprint, the team acknowledges the reality of production emergencies and this helps level out Sprint Velocity.

How does a Sprint Buffer Work?

First, analyze your team’s performance over the last 6 Sprints.
On average, by how much does the team miss its Sprint commitment?

For example, let’s say your team believes they have the capacity to complete 32 Story Points each Sprint.  If your team regularly commits to 32 Story Points, but consistently closes only 26 Story Points and the 6 point miss is because the team is sidetracked by production emergencies, you can face reality and attempt to stabilize Sprint Velocity by giving the team a 20% Sprint Buffer. Reduce the next Sprint Backlog to 26 Story Points. If few or no production issues occur, you can always bring in additional Stories.

Second, track the Sprint Buffer as part of your Sprint statistics.

Every time a team member gets assigned a production issue or emergency to work on, add a Buffer Story to the Sprint Backlog. Do not assign the Buffer Story any Story Points or assign it zero points, because it does not contribute to your Sprint. At the end of the Sprint, record the number of unplanned Buffer Stories completed by the team along with Sprint Velocity as part of your statistics.

Combine Bugs with Project Work in the Backlog

Review every Buffer Story the team is asked to work before adding it into the Sprint Backlog. Is the issue truly an emergency? If the issue is not System Down or there is a workaround to the problem, put the issue into the Backlog as a Bug.

At Story Grooming, size the Bug along with the Stories written by the Product Owner. With a combined Backlog, both new Stories and Bugs can be planned for and brought into Sprints. This technique also helps reduce the Sprint Buffer, while increasing predictability.

Why should planned Bugs get Story Points? This forces the team to think about the level of effort required to fix them. Depending on your Sprint goals, your Product Owner now has the luxury of weighing the amount of development work that must be completed in the upcoming Sprint against the business need to fix high-priority Bugs.

Review the Sprint Buffer Every 3-4 Sprints

The number of production issues worked on each Sprint can vary widely and be unpredictable. Plus, now your team is working on both Bugs and development Stories pulled from a combined Backlog. Every 3-4 Retrospectives, review the number of Buffer Stories that truly require immediate resolution and adjust the Sprint Buffer if needed.

Acknowledge Sprint Buffer Risk to Release Dates

I realize that reducing the team’s capacity appears to dramatically increase the risk that your team will not meet its release dates. But, you already had the same risk, when you missed your Sprint commitments on a regular basis.

Now, however, if your team is on a tight schedule, you raise the realized risk to management and the Sprint Statistics explain the cause. Enlist management to help your team decide criteria for Emergency (work now) vs. Backlog (work when have time).

I’d love to learn how your team manages production issues with project work. Do tell.

 

 

Cynthia Kahn

Cynthia Kahn

 

Cynthia Kahn
CynthiaK@gsd.guru  503.799.5500

read more

Agile Scrum Story Size for Newbies

An Easy Way to Estimate Agile Scrum Story Size for Your First Sprint

Your team is new to estimating Agile Scrum Story Size. You planned for your first release as discussed in Why Your Scrum Team Needs a Release Plan. Your Product Owner wrote Stories that meet the criteria described in Write Better Stories and Why Every Story should have Acceptance Criteria. You have candidate Stories for your first Sprint Backlog.

You are ready for your first Story Grooming Session.

Two activities occur at Story Grooming:

  1. Review Stories for clarity, to ensure everyone understands the requirement.
  2. Assign a relative Size to each Story, so your team can begin tracking Velocity.

Your team should be able to decide whether or not the Story makes sense. However, deciding relative Story Size often causes consternation for new teams. Most teams are happy to move away from estimating work in hours. But, when you are new to the concept of relative sizing, it’s hard to know where to start.

Some are taught to use tee shirt sizing: Small, Medium, Large and Extra Large. But, that doesn’t quite help assign a numbered-size, does it?

Many are taught to assign Story Points based on the Fibonacci Sequence: 1, 2, 3, 5, 8, 13, 21 … We are taught that each number in the sequence represents twice the level of effort as the previous number. But, that doesn’t really help either.

In Agile Scrum, we learn that accepted Stories must be validated as ready to move to Production. Therefore, the level of effort for each Story must take into account the complete development lifecycle, from design to spec to code to code review to quality assurance testing.

Start with the Development Lifecycle

At GSD Mindset, we teach newbies to initially size Stories using the Fibonacci Sequence based on their gut feel for the level of effort required to complete development lifecycle aspect of each Story.

We recommend the following guidelines to help new teams get started:
Size the Story based on the effort it takes for 1 Developer and Tester to complete it.

For a two-week Sprint:

If the team thinks the Story takes 1-2 days of effort, assign 1 or 2 Story Points
If the team thinks the Story takes about a half week of effort, assign 3 Story Points
If the team thinks the Story takes about a week of effort, assign 5 Story Points
If the team thinks the Story could take the entire Sprint, assign 8 Story Points

If a story is larger than 8 Story Points, divide it into multiple Stories. We do not recommend bringing a Story larger than 8 Story Points into your two-week Sprint.

Use an easy method for group estimating like Planning Poker to reach consensus.

When discussing individual estimates, always question extreme high and low estimates. We all know that some requirements are quick to code, but complicated to test. If the team has trouble deciding, error on the side of caution, especially for your first Sprint.

If the Story is not well understood or cannot be sized, 3 things should happen:

  1. Update the Story and Acceptance Criteria to be clear
  2. Break down large Stories greater than 8 Story Points into smaller Stories
  3. Place vague Stories back into the Backlog for refinement

How Many Story Points for Your First Sprint?

If our initial sizing method dictates that it takes a Developer and Tester an entire two-week Sprint to complete an 8-Point Story, we recommend the team bring in 8 Story Points per Developer. For example, if the team has 1 Tech Lead (who doesn’t code), 4 Developers, 2 Quality Assurance Testers and 1 Business Systems Analyst, bring in 32 Story Points.

Then Develop Your Own Method of Story Point Estimates

After one or two Sprints, review the accuracy of your Story sizes (you’ll only be right half the time) and use the Stories the team feels accurately represent a 1, 2, 3, 5 and 8 as examples during Story Grooming going forward.

Don’t overthink it.

And please, please, please don’t estimate in hours.

I’d be interested to learn how your team got started.

 

 

Cynthia Kahn

Cynthia Kahn

 

Cynthia Kahn
CynthiaK@gsd.guru  503.799.5500

 

read more

Core Project Management Functions must Continue after Transition to Scrum

Who on your Scrum Team should Perform these Core Project Management Functions?

You’ve convinced your bosses to let you introduce Agile Scrum into your company and you’ve picked your pilot project. You gathered your team, trained them, you’ve enlisted an enthusiastic Product Owner, and now you are ready to rock.

As you get a couple of Sprints under your belt, you begin to realize some Project Management functions that were performed by a PM in the waterfall world may still be needed. What are they and who performs them now that you’re Agile?

  • Financial Reporting: How much will this feature set cost?
  • Risk Management: Who tracks risks and issues?
  • Documentation: Do we still need documentation and if so, who writes it?

Here at GSD Mindset, we have some practical ideas on how to approach this.

Financial Reporting

There are very few organizations that give you a pile of money and tell you to go have fun. Today, most companies want an accounting of how funds have been allocated. In the waterfall world, Project Managers report out the status of the monthly budget, using techniques like Earned Value to calculate where you are in relation to money spent.

Now that you’re Agile, good Project Management dictates that you still need to keep a financial accounting. In fact, many companies require careful accounting as a legal requirement. It’s not so hard to track and forecast expenses when you transition to Scrum.

After a few Sprints, you use Velocity to determine how many Story Points you can complete in a Sprint. If you know your monthly team budget, you can also calculate the average cost per Story Point. Multiply that cost to the estimated Story Points for the remaining Stories in your backlog for each Feature or Epic and now you have a rough idea of the amount of funding required to complete the remainder of the project.

Keeping on top of the financials will go a long way toward keeping management happy.

Who should track financials? Since calculating cost is similar to calculating Velocity, we believe this is a task best performed by the Scrum Master.

Risk Management

With Scrum, you should have less risk, because you deliver more frequently to customers, but that does not mean you can quit tracking and analyzing risk when you transition to Scrum. There are many ways to identify and track risks now that you are Agile. I find MindTools article on Risk Analysis and Risk Management helpful. 

Risk analysis and assessment should be a team effort. The Scrum Master should lead the discussion during Sprint Planning and conduct a quick checkup at Standup half-way through the Sprint.

Check out our blog post Reduce Risk on a Scrum Team for more ideas.

Documentation

Most software folks are loathe to create documentation. This goes for writing User Guides and Specs all the way down to including Comments in lines of code. Documentation is an important tool to help future users understand what it’s all about. Documentation is a necessary Evil for those of us who remain in a world where our projects are audited. Even in Scrum, we follow a process and our implementation of that process may be audited.

The level of documentation should be decided at the beginning of the project. There are many tools to help you decide and document the minimal amount of documentation your project should require. Many companies today have Project Management Offices (PMOs), and they provide either written guidance or a tool for capturing this list. The final list of necessary documentation should be a part of your Definition of Done.

Once you’ve determined what needs to be written, you need to figure out who’s going to write it. Writing documentation is the responsibility of the entire team. The task to write or update documents should be included as part of the the Story. Because Stories are small changes to functionality, the level of documentation for each Story will be small compared to the size of documents completed at the end of large waterfall projects.

Hopefully, these ideas will help you figure out how best to tackle other traditional project management tasks that may be missing from your Scrum Team practices. Remember, it’s all about teamwork, team empowerment, and team accountability, so figure this out together as a team.

For more advice on how to transition more traditional project management roles, I recommend our blog post Agile Teams Still Need Traditional Support.

 

 

Gerri Slama Grove

Gerri Slama Grove

 

Gerri Slama Grove
GerriG@gsd.guru

read more