Capacity Management

How much wood would a wood chuck chuck if a wood chuck could chuck wood?

When planning work for an upcoming planning increment or sprint, capacity is your available bandwidth for the iteration measured in a well-understood standard unit. At Streamline we use three different units depending on the level of granularity of the requirement objects we’re planning. We touched on these units in the entry on estimation.

Practitioners of traditional project management sometimes think that agile processes are informal because they can’t get a formal estimate in hours for a months-long work plan. The PMP and the Agile Project Manager go around like this:

PMP: “How can this development team possibly know whether they can meet the client’s deadline if they don’t dig in and come up with a detailed estimate before starting?”

APM: “Have you ever seen an estimate stand unchanged throughout the duration of a project?”

PMP: “No, of course not. That’s what change management is for.”

APM: “So even if I were to commit my people to producing a detailed estimate now, you agree that it would be wrong?”

PMP: “Certainly not. I expect your people to provide an honest, accurate estimate!”

APM: “They always do, based on what they know today. Tomorrow they’ll realize they misunderstood the impact of some of the requirements. Or the requirements will change. If their initial estimate was based on high-level deliverables, we’ll still meet the deliverables while managing the details underneath.”

PMP: “I still don’t understand why you can’t just give me an estimate in hours…”

APM: “Fine. It’s eight thousand hours.”

PMP: “Thank you.”

The Agile PM knows that eight thousand hours is the typical capacity of her four scrum teams across four sprints, and the project in question has a deadline that’s five sprints out. She could have said “four sprints,” or “five hundred story points,” but the PMP only works in hours. Sometimes you’ve just got to speak your audience’s language.

Planning Increment Capacity

At Planning Increment (PI) Planning, we’re planning features, so we think of capacity in terms of sprints. A planning increment is four sprints long, and we have four scrum teams. So our PI capacity is sixteen sprints. We’re not yet ready to estimate the child stories of the features, and we haven’t even discovered all of them. At this level we estimate features in “ideal sprints” – how many sprints would this work take if it’s the only thing that one team worked on? A feature that’s estimated at four sprints will absorb all of the capacity of one team for the entire iteration.

Such single-treading is not likely to be acceptable – we always need to get some other items done too. We decompose features that are estimated at more than three sprints and push the lower priority functionality to the next planning increment. As often as not, those lower priority parts of the feature will end up being changed or dropped anyway.

Sprint Packaging Capacity

When planning sprint packages, the capacity currency is story points, and we base our assumption about each team’s capacity on their past performance as measured by their velocity. Velocity is the team’s average story point delivery over multiple sprints. When using it to plan capacity, it is imperative to consider any special circumstances for the coming sprint. Is anyone taking an extended vacation? Do we expect any contention for team members’ time – like a new client going live? (In a perfect world, client go-live would never impact the development organization, but our world is not perfect.)

While at PI Planning we’re thinking in terms of the average team, at sprint packaging we know which team we’re working with and we know their actual velocity, which might be below or above average. We’re also using the estimates on the user stories that they provided. Across our organization, sprint packages can vary by ten to fifteen points due mainly to the teams’ variance in their estimation scales. They aren’t supposed to vary, they’re all supposed to be using “Ideal Developer Day” story points. But the reality is that they do vary, and we very consciously never compare velocities across teams.

Sprint Planning Capacity

After sprint kickoff, each team digs in and plans their tasks for the sprint. Before they start decomposing and estimating, they spend a few minutes estimating their capacity. Microsoft Team Foundation Server (TFS) allows each team member to say how many days they’ll be unavailable (if any), and also to specify how many hours a day, on average, they’ll be devoting to the team. We assume six hours out of our eight hour day, allowing the rest of the time for non-team meetings, training, and admin tasks like timesheets and, you know, getting up and walking around. (Before you ask, lunch is not part of the eight hours.) If someone is a manager, or they have other responsibilities (for example, our architects are on both the architecture team and a scrum team, so their scrum team capacity is reduced), their hours per day will be less than six. TFS also knows how long the sprint is, so it calculates the team’s total capacity in hours for the sprint. Then the team estimates their planned tasks. If the planned tasks exceed the available hours – the sprint capacity – they go back to the product owner to renegotiate the package.


PMP: “Thanks for the demonstration. The client is thrilled. I’m amazed that you guys pulled it off without really knowing how much work it would take. I know you made up that estimate of eight thousand hours.”

APM: “Yes, well, sometimes you get lucky.”


Ceremonies: Sprint Review and Solution Demo

We’re working our way through Streamline’s ceremonies. Next up are the Sprint Review, when teams show their completed work to their product owner, and the Solution Demo (we call our software products “solutions”), when they show stakeholders the great new features that they’ve completed.


Sprint Review

A scrum team can decide at any time during the sprint that an item is done and schedule a review of it with the product owner. As always, done means it meets all requirements of the Definition of Done. All Sprint Reviews must be complete by the end of the last day of the sprint – every third Wednesday.

A single item review can take as little as fifteen minutes and does not need to include the entire scrum team. The product owner can decide whether to invite any stakeholders – sometimes a stakeholder is anxiously awaiting resolution of a bug, so they want to see it. But as often as not, it’s just one team member and the product owner reviewing the item.

All of the components of the longer sprint review ceremony are there: The team member shows the user story or bug description and conditions of acceptance. He demonstrates the working code in whatever environment the team’s definition of done requires. She shows that all conditions of acceptance are met, and shows standard DoD items, like successful test plan execution, unit test code coverage, and updated documentation. The product owner gives the item a pass or a fail. She might also provide some feedback about how the item should be demonstrated at the Solution Demo – what specific test data to use or what use case to follow, for example.

If an item doesn’t pass its sprint review, the team is allowed to try again, as long as there’s time in the sprint. This should encourage the teams to knock things out and get them reviewed in case there are any problems. In reality, we have yet to see this become the pattern. It is acceptable for a team to hold everything until the end and review it then. That just means they have only a few hours to prepare for the Solution Demo.



Solution Demo

Our sprints end on Wednesdays. Solution Demos are on Thursday. Not all solutions (we have five) get a Solution Demo after every sprint. If a solution is in maintenance mode, solution management may not schedule a formal demo of bug fixes and component upgrades. They might simply invite interested stakeholders to the sprint reviews.

While Sprint Reviews are held by each team, Solution Demos can be multi-team if we have more than one team working on the same solution. The teams are expected to coordinate their demos if their work touches – say one team built functionality that feeds the other team’s functionality. They are expected to coordinate what account they use and what environment they demo it to present a seamless show. Teams often prepare a slide deck to highlight the business value that they’re demonstrating. They don’t show the user story and conditions of acceptance. They don’t show any code or test plans or design artifacts. The items being demonstrated have already passed the sprint. The Solution Demo is a show.

The solution manager hosts the show and sets the agenda, rather than the team. She may have some introductory remarks, and she always congratulates the team, often providing context for their success, such as “despite having four unexpected client issues during this sprint, the team delivered everything they committed to, including this bright, shiny new feature that you guys all want.”


Sprint Reviews throughout the sprint sound great on paper. The teams get early decisions and have time to regroup, or to prepare a great show for stakeholders. The product owners don’t have to block out a big chunk of time on the last day of the sprint – being available for short sessions throughout is easier.

But after three sprints under this structure, most teams are still not scheduling sprint reviews earlier than the last day for most items. The end-of-sprint review is deeply embedded in our culture, and change comes slowly no matter how great an idea it is.

Some teams see the Solution Demo as just an extra meeting. However, others have brought their A-game to it and overall stakeholder enthusiasm for the new format is very good.

Ceremonies: The Daily Standup

In this third post about Streamline’s ceremonies we look at the scrum daily standup, the value it adds, and how our teams overcome challenges that they encounter with it.


Daily Standup

Suggestions and strategies for conducting an effective daily standup abound on the Internet and in published material, so in this post we’ll endeavor not to be an echo chamber.

A key element to successful scrum practices is team communication. Everyone should know what everyone is working on so that if a team member is struggling someone can help them. Everyone should be able to contribute to problem solving or creative engineering. Most of the authorities out there refer to this open sharing of information as “information radiation.” Your tools, whether software or index cards on a wall, should make the team’s situation visible to all members (and non-members, for that matter) – or “radiate information.”

Think about “radiation” for a moment. When you walk past a heater, you feel the warmth without seeking it, and you can’t easily avoid it. In technology terms, radiation is somewhere between “push” and “pull” notification. A team member overhears a conversation between team mates standing near her desk. Or the task board is displayed on a wall that he can’t avoid seeing it when he gets up from his workstation.

These examples assume a key element of scrum best practice: co-location. But for many organization, the glorious target of totally co-located teams is simply not possible. It’s pretty unlikely — short of constant audio and video connectivity — that your tester in India is going to overhear two engineers arguing about code design in your Kansas City home office.

That’s why the daily standup is even more important for distributed teams (although it’s important for co-located teams, too). You know that at least once a day everyone hears how everyone is doing.

Our standups are scheduled to take fifteen minutes. That’s a careful choice of words, because they do sometimes run over. The bigger the team, the more time it takes to get through all the updates and the more often things will get off track and have to be redirected. This is one of many good reasons to limit team size to 7 +/- 2.

Our scrum masters are responsible for scheduling the standups (actually setting up the recurring appointment in MS Outlook, providing the screen sharing set-up and conference call), and for moderating them. Every team member is also empowered to moderate if the scrum master fails to do so – they are human and can get into the weeds when they’re passionate about something.

Some of our teams continue the practice of standing up for the standup. Some have slipped into sitting down around a conference table. These are the teams whose meetings tend to run over. When asked about it, it’s clear that it’s a Catch-22 situation:

“Why are you sitting down in your stand-up?”

“We sit down because the meeting runs long.”

“Why do you let it run long?”

“We get into discussing how we’re going to do something.”

“Isn’t that outside of the ‘what I did yesterday, what I did today, and whether I’m blocked’ agenda?”

“I guess so, but since we’re all sitting together, we do it.”

In fact these design and other discussions are the kind of information you want radiated to the whole team, so we leave it to them to self-manage. If their long stand-up is proving useful, then let them sit through it. To be sure, if someone finds them tedious they’ll say so during the retrospective.

The rule that’s absolute in our organization is attendance at your team’s standup. If you’re working today, you are required to participate. If you absolutely can’t (some of our folks get called into non-optional meetings with clients, for example), you are required to provide a written update to your team. While you miss out on hearing what they’re doing, at least they hear from you. People on vacation or sick are not required to attend the standup, although they sometimes do. We do believe that time off is time off.

All teams set up a conference call and screen share for their standup, both for distributed members and for co-located members who are working from home that day. All of our teams use Microsoft Team Foundation Server and Visual Studio, so our tools provide a virtual task board and burn down for each team that can be shared during the meeting (although the remote people can also access it on their own).

Our product owners do not consistently attend team standups. They might drop in, or they might be invited in by the team. Other stakeholders rarely drop in, although they are allowed to. This can be risky, and it’s better if the product owner is also there to manage their expectations. The level of technical detail shared in the standups is often not accessible to most of our stakeholders, and they could draw incorrect conclusions about the status of the sprint based on the team’s discussion on one day. Depending on the stakeholder’s personality, there’s a risk of their questioning what they hear to a degree that disrupts the team or even attempts to change the requirements without product owner involvement. It’s good for teams to hear directly from stakeholders, but it’s critical that action based on stakeholder input be funneled to the team through a single source: the product owner and prioritized requirements. I know that may sound anti-agile. If our stakeholders were continuously engaged with the teams – collocated, and absorbing radiated information — then they’d understand the scope of each work item and filtering would be unnecessary.

The daily standup is a critical component to continual advancement of the sprint. It’s a checkpoint that helps every team member think every day about goals and accomplishments.

Streamline Health’s Lifecycle Practices

Streamline Health develops software solutions that support revenue cycle optimization for healthcare enterprises. Streamline’s Innovations department is responsible for creating and maintaining our software products, from requirements gathering through to delivery of releasable code to our client services team. This blog is presented by members of the Innovations team to share our application lifecycle best practices, challenges, and the insights we gain as we grow.

In January, 2015 we implemented the Scaled Agile Framework to manage our five separate software products and development teams. This included formal scrum training for all of our development team members, whether or not they were already “doing” scrum. SAFe helped us to normalize our release planning and code delivery schedule by synchronizing our scrum teams’ iteration cycle. At the enterprise level, SAFe helped us bring diverse development efforts into focus so that resources could be better aligned with corporate objectives. Since that launch we have continued to refine our practices and process.

In 2017, we’re kicking off ongoing ALM training. Our goals are to refresh people across our organization about our best practices, to bring new team members up to speed, and to engage with everyone in the continuous improvement process. Follow along with us as we teach, learn, and improve.

— Mia McCroskey, Director, Solution Lifecycle Management