Practical Software Measurement

The Shape of the Work When Estimating Agile Releases

In a recent webinar on using the SLIM tools and methods in an agile environment, we showed a template for agile projects included with SLIM-Estimate. I was asked, "Since agile teams are a fixed size group that stays together throughout the work on the release, why doesn’t the agile template use the Level Load shape?" My answer was the typical short answer to a complex question, "It’s complicated and it depends." In this blog, let’s take a look at some of those complications and dependencies.

The team, the whole team, or nothing but the team?

When using SLIM-Estimate to estimate the effort required for a release, agile or not, you have to decide, "Whose effort are we interested in?" When describing a team in a scrum project, we usually talk about three major roles: product owner, scrum master, and team member. These people are, in general, full time on the project. If you are only interested in estimating the effort of these full time team members, then you may want to use the “Level Load” shape in SLIM-Estimate. The total effort of these people is based on the number of people multiplied by the duration of the work on the release.

But you may want to use SLIM-Estimate to estimate the total effort required for the release, and there will almost certainly be people beyond that core team that work on the project. For example, the heart and soul of scrum are the conversations about the user stories. The requirements for the release emerge through these conversations. Although the product owner may be ultimately responsible for the decisions on what stories are included, many agile gurus have pointed out that “it takes a village” to flesh out the details and to review the software as it is being built. Those details emerge through conversations with subject matter experts, process owners, customers or customer surrogates, and other stakeholders. To get the most benefit from agile methods, you need these business side stakeholders throughout the project, so the details of the requirements emerge as they are needed, although they may not be full time on the project. You may need to account for the effort of this increased involvement to get the true cost of the project, even if, in more waterfall-like situations, you didn’t track and measure the effort of those stakeholders. Also, there are often specialists (yes, even in agile projects!) that share their time on multiple projects. For example, there are likely deployment and installation specialists, or training and documentation specialists. These people may not be full time on the project, but the success of the release depends on their participation. You may want your effort estimate to account for their effort. Judiciously using the various Rayleigh shapes available in SLIM-Estimate can predict the total effort needed.

Team of people or team of teams?

Large organizations are looking to frameworks to apply agile methods to large projects and portfolios. While there are many such frameworks, most rely on the notion of forming a “team of teams” (or as it’s often called, “Scrum of Scrums”), with each team about the size of a typical agile team, maybe 7 plus or minus 2. There can be 5, 10 or more such teams working together on the project. How does this fit with the effort curve shapes in SLIM-Estimate? While each team may stay together throughout their work on the project, you may be adding and removing teams as the work of the project demands. (Note: not all agile frameworks describe it this way.) So you can see the familiar Rayleigh shape to the staffing, but your staffing unit is “team” rather than “person”. Instead of rolling individual people on and off the project as the Rayleigh curve predicts, you would roll entire teams on and off. For a portion of the time you may have a few people more or less than the curve predicts, but you get the advantage of the team members forming cohesive units, and that can reduce team communication issues and improve productivity.

Splitting time between two types of work

SLIM-Estimate estimates effort based on the Phase Tuning settings, and one of the key settings is which Phases are included. What? Phases in an agile project? Sounds too much like waterfall! But “Phase” within SLIM-Estimate has a specific meaning that applies in agile projects just as well as other methodologies. Think of “phases” to mean “types of work” rather than “sequential periods of time.” In particular, for agile development, we suggest you distinguish, estimate, and track at least two types of work: Story Writing and Story Development. Story Writing includes deciding what stories to include and creating the typical agile user story cards. In addition to the brief descriptions written on the cards, Story Writing also includes the work of refining the details of the stories, whether those details are written down on paper, in electronic form, or as many agile gurus suggest, perhaps not written down at all but brought out through conversations among all the participants.

It's key to agile success that this work is a team effort. The conversations include the "village" of stakeholders and the product owner of course, but also directly include the developers, testers, and other team members that will create the code. Story writing also includes the prioritization discussions that help choose the development order, and other activities to "groom the backlog."

Story Development translates the stories into working software. This includes coding, testing, documenting, and all other activities to prepare the software for deployment and use. This is done by the core team, together, as we noted, with people in specialist roles that may not be full time.

In the SLIM tools and methods, you can estimate and track these two types of work separately. There are both theoretical and practical reasons for doing so. The theoretical reasons involve how the Putnam model and the software equation, together with statistical trend data, are used in the SLIM-Estimate computation engine. The details are beyond the scope of this blog. The practical reasons are that the people involved likely track their time differently using different tools. In particular, the stakeholders from the business side are not likely entering time against story records in an agile tracking tool, and even the developers involved may only be entering their coding and testing time in the agile tracking tool. The effort for Story Writing may be tracked elsewhere, or you may need to approximate it through observation of the work—that’s a polite way of saying someone may make an informed guess at the actual effort of the people involved to track it. But such guesses are often made well and provide valuable data both while the project is on-going, and as the basis for later use by computing trends for estimating new projects.

When you look at how the total effort is split among these two types of work or phases, three things stand out:

  • Story writing has significant participation from people who are not full time on the project
  • The people who are full time split that time between the two types of work in an uneven way
  • The amount of effort expended on each individual type of work is NOT constant throughout the project

We described this in more detail in one of our recent webinars.

The upshot is that the shape of these two types of work or phases in SLIM-Estimate can be best predicted by Rayleigh shapes, rather than Level Load. Which Rayleigh shapes depend a lot on specifics of your methods (there’s that answer, “it depends,” again!). We have some suggestions in our agile template based on some common patterns, but you may want to adjust those.

So how does this fit with the idea that "the team stays together full time?" If you combine the Rayleigh curves for the multiple phases, you almost get the level shape. It includes the full time product owner, scrum master, and team members for the duration of the project, but also includes the varying, part time participation of specialists and the "village" that’s grooming the backlog.

Maximum utilization vs maximum throughput

One of the arguments against moving resources on and off a project in order to maximize resource utilization comes from the Lean Development movement. One of the lessons manufacturers have learned from the Toyota Production System is that keeping machines working at maximum capacity is counter-productive, because you do not have the capacity you need to handle unexpected bumps in demand. Maximizing throughput is more valuable than maximizing utilization. A great reference for this is Don Reinertsen’s book, “The Principles of Product Development Flow.” So the argument for keeping the team together is that when a particular sprint for any of a number of reasons requires some extra effort, the team members are there to provide it.

But there’s a long jump between making sure there is extra capacity when you need it and keeping all resources active all the time. You can staff above the minimum estimate without necessarily keeping the team constant. Putnam-Norden-Rayleigh curves, used by SLIM-Estimate to predict effort needed over time, can provide a guide for shaping that excess capacity. While no project will follow the Rayleigh curve exactly, it’s still the best predictor of the natural flow and ebb of the project.

Relay races, the Olympics, and September baseball

Going a bit out on a limb, let’s examine the assumption that an agile team should be a fixed size that stays together throughout the work on the release. Agile gurus propose this staffing pattern for a good reason. Agile is all about team communication, and having the core team together the whole time, often working in the same room, can promote maximum communication. The argument against it is an attempt to maximize resource utilization. If you roll people on an off projects as they are needed, one person can accomplish work on multiple projects instead of "sitting around" waiting for work on a single project.

Agile methodologists love sports analogies (the term "scrum" itself comes from Rugby). One analogy used against the idea of "maximize resource usage" is the Relay Race. When four runners form a team to run a relay race, they all line up together and they all participate fully from beginning to end of the race. You can see the intensity on their faces as they wait for their individual leg. It’s a team from beginning to end and no runners would ever consider doing something else while their teammates are running the other legs. This sense of intensity, readiness, and communication is the essence of teamwork, and agile teams apply this to their work of coding software.

So what’s the analogy of the race in agile software development? Probably the closest is the "sprint", a short (maybe two week) time-boxed effort where a specific set of stories will be communally developed by the team. It makes a lot of sense to me that keeping the team together during a sprint is a great idea.

But does it immediately follow that this means you should not add team members onto a project or move team members off as the amount of work changes across multiple sprints? Will optimizing the number of team members at any time make the work more efficient or will the disruption caused by changes to the team make it less efficient? We at QSM will not try to tell you what’s right or wrong here, and there is research to be done, as we often do at QSM, by looking to customer data to see the trends. But let me offer a couple of other sports analogies that may be at least as applicable as the relay race.

When the entire Olympic team participates in the opening ceremonies each year, you can see the comradery and the team spirit. But as the games progress, athletes come and go based on when their events are held. While the team for an event stays together for that event like the relay race, the overall team is not constant for the duration of the Olympics. And the athlete that’s completely focused on her team during the 4 x 100 relay may "roll onto another project" the next week to run in the 400 meter race.

I’m personally not much of a sports guy, but I do like baseball. Through most of the season, the roster has exactly 25 people. That’s the rule. But they're not the same people all year. A right handed relief pitcher may be sent down to the minors when there’s a stretch against teams where a left hander would be more useful. It’s particularly exciting in September, when the team expands to 40 for the end of the pennant race, as the major and minor league teams trade off players based on the need in minors for playoff games and the need in the majors for extra help down the stretch.

Consistency on a software development team brings advantages with the close teamwork it can engender, but let's be careful about all or nothing solutions to any problem in software development. One size does not fit all.

So what’s an estimator to do?

We see that for a variety of reasons, a simple Level Load shape in SLIM-Estimate may not always be the most appropriate for estimating agile projects, even if your core team stays together. So what's the right shape to use? You can start with the shapes for the phases in the SLIM Agile Story Point template that is included when you install SLIM-Estimate. But as you gain your own organizational history and you see what staffing patterns are most useful for your variations on agile methods, you will want to modify and customize that template. You may need multiple templates for different types of releases. New products or major innovations to existing products may need different shapes from minor enhancement releases. Mission critical projects may need more "front loaded" shapes for story writing so that people throughout the organization can give input early enough. There’s no simple, single answer that will work for every agile project. After all, it’s complicated and it depends.

 

Blog Post Categories 
Agile