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

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

Why Your Scrum Team Needs a Release Plan

Scrum Release Plan Sets Expectations with Management

When teams transition to Agile Scrum, they may decide the only required planning is Sprint Planning. These teams feel that because they are Agile, they don’t have to plan beyond the next Sprint boundary.

Most of us work in a corporate world, where upper management wants to know when the project is expected to finish and the estimated completion dates for major features and interim deliverables. Since these managers’ budgets pay our salaries, we need to find Agile ways to plan projects and deliver them using Scrum.

Teams that plan for Feature releases can still remain true to Scrum. Both the Scrum Alliance and Agile Alliance mention release planning, but they don’t provide a process to accomplish the task.

For this reason, several methodologies have sprung up to fill the gap and put a project management wrapper around Scrum. The biggest players are Scaled Agile Framework (SAFe), Disciplined Agile Delivery (DAD) and Large Scale Scrum (LeSS).

To be honest, when I look at those websites, I get dizzy trying to read their process diagrams. The processes don’t feel very Agile at all.

At GSD Mindset, we are big proponents for creating a Release Plan, but we advocate an approach that more closely aligns with Agile and Scrum.The top half of the GSD Scrum Funnel© illustrates our approach.

GSD Agile Scrum Funnel

GSD Scrum Funnel

Simplify the Release Plan Process

  • Divide the application into logical Feature Sets or Epics (in Scrum terms)
  • Break down each Epic into completed deliverable Components
  • Prioritize the Components
  • Organize the Components into a Quarterly Release Plan
  • Start writing Stories for 1st Sprint
  • Release Component functionality and pivot as customers use the product

Most people get the concept of identifying the high-level Features or Epics. From here, Scrum expects the Product Owner to start writing Stories about tiny slices of functionality required to build the Epic. Most new Product Owners find it difficult start with the concept of a completed Feature and immediately know what Stories to write. The intermediate step of breaking down an Epic into its Component deliverables fills the gap.

Prioritize Component Deliverables for Each Epic Before Writing Stories

Once every Epic has been broken down into Components, you can group those Components into Quarterly Releases. There are many prioritization techniques. My personal favorite is defining the Minimum Viable Product (MVP) or Minimum Marketable Feature set (MMF). Think as if you could lose funding if version 1 of the product does not meet customer needs by the end of the first quarter.

If you only have one quarter to prove the value of the product, then what must be delivered? This is a very real concern if you work at a startup or a company with budget constraints. Going through this exercise helps ensure your team delivers the highest value Components first.

Once you know the highest value Components, it’s much easier to write Stories and plan for the first Sprint.

Status Report Against Release Plan

Now, even without knowing your team’s Velocity, you can provide upper management with a Quarterly Release Plan or the list of Components your team plans to deliver each quarter. The team can status report against the plan. Once you know your Velocity, you can size the Components and begin reporting percent complete.

For more details on the GSD Mindset simplified approach to developing a Release Plan, check out:

I’d love to hear about your team’s approach to planning.
Do comment.

 

 

Cynthia Kahn

Cynthia Kahn

 

Cynthia Kahn
CynthiaK@gsd.guru  503.799.5500

read more

Scrum of Scrums Manages Cross-Team Commitments

Scrum of Scrums Facilitates Coordination across Teams

Agile Scrum teams are generally organized around projects or core capabilities, where teams support a set of products that serve a common business purpose. When Scrum teams are organized around core capabilities, project initiatives often require deliverables from multiple capabilities. Even Scrum teams specifically organized to deliver a single project can find themselves in need of functionality built by another Scrum team.

Almost every Scrum team in a company large enough to form multiple Scrum teams has cross-team requirements, but very few companies take advantage of Scrum of Scrums. With a strong commitment to the spirit of cooperation and a little organization, cross-team product or project deliverables can easily be managed through the Scrum of Scrums concept.

The Scrum Alliance and Agile Alliance both talk about the Scrum of Scrums technique, but they recommend holding this coordination meeting every day. We think that’s overkill. We think holding a well-organized Scrum of Scrums every other week is good enough. For those who practice two-week sprints, hold the meeting on the off week from Sprint Planning.

Start with a Plan

Every Scrum Team needs to plan. If your Scrum team is not release planning or identifying quarterly deliverable goals, then start today. Before you jump up and down and tell me you can’t plan because you’re agile, cool your jets. I’m not saying you need a 500 line Microsoft Project Plan; I’m saying you need deliverable milestones by Epic. Why? So, you can identify when you need product deliverables completed to stay on schedule.

If you don’t know how to plan for Agile, read Chapter 2 of the GSD Scrum Handbook: GSD Gold Project Planning.

Once you know what you need and when you need it, then you can approach your sister Scrum teams and negotiate delivery dates.

Meet Regularly to Stay on Schedule

Once you have delivery commitments, ensure all Scrum teams stay on schedule by meeting once each Sprint. Remember that not all Scrum teams are on the same Sprint cadence, so be specific about due dates. Give your sister Scrum teams plenty of lead time to get your needs on their Backlog.

Use the Scrum of Scrums meeting time to ensure the right Stories get brought into the right Sprints.

Who runs the Scrum of Scrums?

Depending on the formality of company processes, the scope of the project and the Scrum team structure, the Scrum of Scrums can be chaired by any one of many job titles. With more formal team structures, these meetings may be led by the Program Manager or Project Manager or Product Manager. With less formal teams, the Scrum Master who needs the external deliverables may take the lead.

What Happens at the Scrum of Scrums?

Keep the Scrum of Scrums to a half hour meeting.

Focus only on cross-functional deliverable dependencies:

  1. Start the meeting with a brief review the upcoming quarterly or release milestones.
  2. Verify that the Stories identified for completion in the previous Sprint were completed.
  3. Identify Stories for completion in next Sprint. Obtain commitment from sister Scrum Teams.

What the meeting IS: a meeting about dependencies, shared milestones and issues.
What the meeting IS NOT: a giant Standup or project status meeting.

When your project or product requires cross-team coordination, taking advantage of Scrum of Scrums can keep everyone focused on the right work at the right time.

I’d love to hear about your successful use of the process.

 

 

Cynthia Kahn

Cynthia Kahn

 

Cynthia Kahn
CynthiaK@gsd.guru  503.799.5500

 

read more

Techniques to Increase Sprint Velocity

Try Applying these 3 Techniques to Increase Sprint Velocity

In agile scrum, we only count closed stories when we calculate velocity. Stories have only 2 statuses at the end of the sprint: 0% or 100% complete. No partial credit for incomplete stories.

Many teams refuse to accept this fact. Scrum does not give partial credit for the simple reason that incomplete stories cannot be delivered to the customer, so they have no value. Because priorities can change at the speed of business, incomplete stories may not rank high enough to be prioritized for the next sprint. If that code was checked in, the code changes for those partially finished stories have to be backed out, which causes even more work that adds no value.

We have found the following 3 techniques help the team close more stories, which improves burndown and results in increased velocity:

  1. Write smaller stories
  2. Ask when story will close
  3. Adopt shared test mindset

Write Smaller Stories

Do your developers pick up stories at the beginning of the sprint and work on the same set of stories for the entire sprint? Does your burndown chart look more like a plateau with a cliff at the end? If this frequently happens with your scrum team, then your stories are probably too large.

Look at your backlog. How many 1 and 2 point stories has your team written? None? Are they all 3 or 5 or even 8 points? If you answered yes, then streamline your approach to story writing.

Remember that a story performs a single function. Take a serious look the slice of functionality defined in your larger story requirements. If your stories describe requirements for multiple, yet related functions, then divide and conquer.

Ask When Story Will Close

At daily standup, the development team answers the following questions:

  • What did I do yesterday?
  • What will I do today to meet the sprint goal?
  • Do I have any impediments?

To keep the eye on the prize and focus on closing the story, we suggest you ask an additional question every day when you discuss the status of every story:

  • When do I think this story will close?

The answer to this question provides insight into the true status of the story. If you don’t like the answer, immediately follow up with: Why? The answer to these two questions help identify the proper next steps, which could include clarify requirements, get help from tech lead or pair the developer with another programmer.

One of the pillars of scrum is transparency. Be honest with each other. Ensure stories that languish get the attention that they need to close.

Adopt Shared Test Mindset

To produce quality products, we recommend scrum teams take a 3-pronged approach to testing:

  • Test driven development
  • Write QA tests when the Story is picked up
  • It’s everyone’s responsibility to test  

If your development team does not have automated testing goals, add them to your team’s contract. Every time you add new functionality to a program, apply the iterative concept of Test Driven Development (TDD): write a failing automated test first, then write the code so the test passes.  

We recommend getting testers immediately involved when the story is picked up for development. Early involvement by testers, who write test cases based on the acceptance criteria, avoids having those resources sitting around for half the sprint waiting to test. It also ensures the team is ready to test immediately after the story is code complete.    

Agile scrum holds the entire team responsible for completing the story. That means testing is everyone’s responsibility. If stories get backed up waiting for testers to test, other members of the team must pick up the slack to get all stuff done on time.

If your team successfully applies these techniques or other techniques that result in a smooth burndown and increased velocity, we’d love to hear them.
Do share.

Cynthia Kahn

Cynthia Kahn
CynthiaK@gsd.guru  503.799.5500

read more