Sprint Package Management

Some organizations practicing agile simply maintain a prioritized backlog and have their teams pick up each item as they have bandwidth. The product owner and the team know the team’s velocity and therefore have an idea of how many items they’ll complete. At Streamline Health we take a more structured approach for two reasons:

  • When teams are just forming and adopting scrum, clear goals and commitments make it easier to form disciplined habits. Once this practice is in place, there’s little need to change it.
  • Sometimes we must make commitments to clients, so we have to know for sure whether an item will be done in the next sprint.

Therefore, at Streamline, our product owners package each sprint and our teams commit to delivering them. Let’s dive in on what that means.

Planning Increment Planning

We first contemplate sprint packages during our quarterly planning increment (PI) planning session. The primary purpose of these sessions is to revisit and adjust the overall direction of each of our products (what the Scaled Agile Framework calls “value streams”). We market four distinct products that are at different points in their lifecycles. At PI Planning, our executive stakeholders have the opportunity to direct more or fewer teams toward one or another product– say, to accelerate feature development for the newest product that sales is pushing hard, while reducing enhancements on one or more older ones.

We move work, not people, so when one product needs more attention we package that work in the sprints of more than one scrum team. The more intense the push on that product, the more team capacity we allocate, even to the point of putting other products on the shelf.

Even a shelved product has users, though, so as we package new functionality into sprints during PI planning we still reserve some team bandwidth to address emergent client issues on them.

By the end of our two-half days of PI planning, we should have the stories ready for the first sprint in the planning increment. They should be decomposed, refined, conditions of acceptance agreed upon, and estimates made by the team that will do the work. When we have multiple teams working on the same product we often do joint estimation sessions, getting an estimate that all of the teams accept.

We should also have a good idea of what stories will be in the second sprint, some with estimates. And we have an idea of the remaining work in the overall feature-level goals for the planning increment. The teams are asked for a vote of confidence on completing the features in the planning increment. More on that later.

What Could Possibly Go Wrong?

With the roadmap laid out during PI planning, why don’t things go like clockwork for at least the first two sprints? Because priorities change. And agile practices were specifically devised to accommodate these changes

Sales might announce with great pleasure that a new client is about to sign a lucrative contract as long as a specific feature is developed within the next four months. Assuming the feature they’re after is in keeping with the overall direction of the product, no product manager could deny this opportunity to boost sales. There goes the plan!

Client Services or Support reports that a couple clients have started escalating their frustration with a bug that you thought wasn’t that critical. You’re at risk of losing client satisfaction if you don’t fit that bug fix into the next sprint.

Midway through the first sprint of the planning increment, the architects realize they missed something. In order for the new functionality to be scalable and meet performance requirements you’ve got to package some architecture work to harden the backbone. The sweetest features are useless if the system doesn’t perform as expected for the end users.

Marketing comes back from a conference with amazing insights. If we add just enough of these new technologies to the product so that we can say we’re doing it, we’ll get ahead of the competition. This kind of insight might not disrupt the sprint packages in the current planning increment, but you might need to do research spikes to prepare stories for the next PI planning session, and that will steal bandwidth from your current plan.

Factors in Creating a Sprint Package

The product owner uses several data points as well as input from stakeholders to pick which stories to package. The first concern is team velocity: how much work can this team typically complete? Velocity is the average number of story points that they’ve finished over the previous few sprints, omitting outliers.

No single item in a sprint should be more than 50 percent of team velocity. So if a team’s velocity is 27, the largest story they should undertake is one with an estimate of 13 points. They should never be given two 13 pointers. That’s the equivalent of putting all their eggs in one basket. Their package should be one 13 pointer and two or three smaller items that give them room to negotiate if they discover a bad estimate. The smaller the user story, the more accurate the team’s estimate. It would be better to decompose stories so that you never even have any that are half the team’s velocity, but sometimes that’s very difficult while retaining adequate business value to justify the effort.

Items must be independent so that some team members can work on one while others work on another and they won’t step on each other’s code. When multiple teams work on the same product this is even more critical. This can be especially tricky if you address the 50 percent of velocity problem by decomposing a larger story into two or three smaller ones, then package them in the same sprint for the same team. Did you really make them independent? Or did you just divide up the list of acceptance criteria into three and call them different stories? Lazy requirements management has been the downfall of many a sprint.

Team and individual skills and knowledge is the third packaging factor. If one team has a database guru and the other does not, push the data-heavy story to that team. If you’ve only got one team and nobody is great with user experience, you may have to bring in some expertise to work with the team, which will reduce their velocity as they learn from the expert.

Hold about ten percent of bandwidth in reserve. Note that your velocity will already account for this, so if you see that velocity is 30, you don’t reserve ten percent of that and only package 27 points – the 30 point average was accomplished with ten percent of bandwidth already reserved.

But why not consume every possible hour the team has available? Isn’t that wasteful? The effectiveness of Lean practices is widely recognized, and reserving some bandwidth for the unexpected is a Lean principle. In order for a Lean scrum implementation to work, you must trust your team. They aren’t a bunch of lay-abouts trying to avoid work. They’re talented engineers who want to produce a quality product. If they really aren’t, then you’ve got the wrong people, but that’s a different blog post.

During each sprint the team may discover the ability to fix legacy bugs that weren’t packaged. They’re working on a certain part of the code and they can improve it, but it will take more time than they originally planned. That’s an extremely good use of that ten percent you reserved.

Emergencies happen: team members are pulled onto emergent client issues; an additional item “must get done” in this sprint (a bad practice, but sometimes unavoidable); the team miss-estimated so something is much larger than planned; multiple team members get the flu.

“Bench” is not a dirty word in Lean practices, and the time will not go to waste. Even if none of the things listed above happen, team members will use the time productively – on additional testing, on research for upcoming work, on more general learning, on cross-training in areas of the code they don’t yet know. And if they find time for a couple rounds of ping pong that has value too.

Priority Within the Sprint

In that simple model I mentioned at the top, the stack ranked prioritization of the backlog is key, but when you work with sprint packages, the product owner is less focused on the individual priority of each item in the package. They want it all done. However, the team can use individual item priority to help them plan their sprint.

Since the goal of an agile process is to deliver business value, the priority of the items in a sprint should be based on their business value. However, bugs don’t have business value (you already got credit for the value of the feature even though it had the bug, so you don’t get more credit for fixing it). And sometimes fixing a bug is the most important thing to do in a sprint.

Streamline uses Microsoft Team Foundation Server to manage all scrum work, and the form for bugs (rightly) does not include a business value field. So we use the Backlog Priority field, available on both bugs and stories, to prioritize the items in each sprint.

Sprint Goals

The product owner specifies two or three key deliverables for each sprint that represent its “essence.” These goals can relate to just some, or to all of the items in the sprint package. If there are items in the package that don’t fulfill the goals, they are, by definition, lower priority and the product owner’s stack ranking of the items should reflect that. Successfully meeting the sprint goals, as judged by the product owner, means the sprint is a success, even if the team doesn’t complete all of the packaged stories and bugs. This flies in the face of our metrics, though, which are based on pure data as I’ll discuss in a moment.


At the end of PI planning the teams are asked for a “Fist to Five” confidence vote, fist being “no confidence” and five fingers being “confident.” If the teams vote lower than fours and fives, the product owner leads a discussion of the concerns, and it might lead to some further decomposition of the planned features or a reduction in planned scope.

This slideshow requires JavaScript.

Managing the Package During the Sprint

After a confident kickoff the team plans the sprint by breaking down the stories and bug into one and two-day duration tasks. When this is done, if the total estimate, in hours, for the tasks is less than the team’s available time, they’re golden. But what if their task estimates add up to more time than they expect to have?

First they review the items in the package. Have they misunderstood anything? Probably not. Most likely as they planned they identified more complexity than they saw during backlog grooming and estimation. It happens, and that’s why there are so many checkpoints in the process.

First the team should re-estimate the problem story – maybe it was estimated at 8 points, but now they think it’s a 13. The team goes back to the product owner to negotiate. They can reduce the scope of one or more items by removing some conditions of acceptance, then re-estimate them to see if they’re back within velocity. Or they can remove one or more items from the sprint. What gets removed is the product owners’ decision. Whether it’s enough is the team’s.

After negotiating, the team does another commitment vote and, hopefully, digs in on the work.

Success (Failure)

What happens if a team doesn’t finish everything?

The incomplete items are returned to the backlog. They may or may not go into the next sprint – that’s up to the product owner. If something is partially completed, the team is responsible for making the code whole – they might have to shelve changes that are incomplete or untested so that the completed code can be delivered. The team must re-estimate any items that they’ve done some work on, so that their story point estimate reflects the remaining work. Sometimes the estimate won’t change, meaning that the item was underestimated at the start and the team didn’t catch it early on. That’s a sign of an immature team, and something to be addressed in the retrospective.


Traditional project management methodologies run on lots of metrics by collecting lots of data – timesheets, bug tracking, test execution, and so on. At Streamline, the first principal of any metrics around scrum is that we don’t go deeper than the team. We do not look at metrics on individual team members. Obviously we collect data –  timesheets, metadata in Team Foundation Server, and so forth. So we are capable of analyzing an individual’s contribution should the need arise, but we do not do that as a matter of course.

Team and product metrics are what matter. Three useful metrics that we look at are:

  • Sprint Success – did each team finish what they committed to? This is a data-based metric, not a sprint goals assessment, so it’s a little harsher than the more popular goals-based success. We track whether each team delivered to their commitment, over delivered (by taking on additional items after kickoff), or under delivered. While an under delivery is a failure, we do show how much they did complete rather than simply call it a zero. Sprint success is reported to the organization in a monthly round-up of metrics from all areas.
  • Velocity – how much did they get done? As discussed earlier, this is used by the product owner and team to determine how much to package next time. It’s data based, but adjusted to omit outliers (like that sprint when three team members got the flu and they didn’t deliver two stories). Velocity is not formally reported to the organization, but rather used by the product owner in packaging.
  • Business Value — Delivering value to our clients is the primary goal of agile. Business value added by product is a useful trailing indicator that you are indeed enhancing the product that’s the highest priority. For that to work, you must have parity across all products and a baseline for each one (“product X was worth 10,000 points of business value and we added another 300 this sprint”). We’re not quite there yet with this data, but it’s in our plan.

How Are You Doing?

How are you doing at managing sprint packages through their lifecycle? Do you track any other metrics that you find valuable? Let us know in the comments.


Ceremonies: Team Retrospective

At last we come to what some experts say is the most important scrum ceremony of all: the team retrospective. This is the team’s moment for self-reflection. You might also hold retrospectives that include stakeholders and others. Those have a different purpose from the team’s retrospective on their internal workings.


The Team Retrospective

One of the hallmarks of a successful scrum implementation is continuous improvement. Teams that do not conduct regular self-inspection, and that do not find ways to do what they do better, are destined to go the other direction.

After every sprint, it is critical that each scrum team take a few minutes to review. They should use this time to recognize success as well as identify weaknesses. While the sprint reviews and the demo offer the opportunity to recognize their work product, the retrospective is when they recognize how they work.

The retrospective must be a peer review – rank or management relationships are irrelevant. Every team member must be empowered to speak their mind. If the team’s culture doesn’t allow frank discussion, then it’s not a viable scrum team. You need to fix that before the team can achieve truly great agility.

The retrospective is the litmus test for a team’s maturity.


There are many ways of running a peer review or post implementation review. In all of them, the goal is to gather input from everyone without judgment, document it, and identify the most critical concerns – the areas that it’s most important to improve on.

The agenda we use at Streamline Health is the “round the room” technique:

Go around the room, asking each person to offer one thing that went well during the sprint. Write each contribution down as stated. Keep going around the room until nobody has anything else to add. But enforce the “one item at a time” rule. This prevents any one person from dominating.

Then go around the room asking each person for one thing that needs to be done better. Language here matters to people – don’t ask for “what went wrong” or “what failed.” This allows team members to suggest improvement to their peers without actually saying “you failed at …” As with the positives, keep going around the room until nobody has anything else to add.

Typically, the “things to improve list” is longer than the “we did great” list. That’s good. It’s a sign of a team that recognizes its weaknesses and wants to improve.

The final step is voting. Each team member gets to vote on her top three (or four, or two — whatever seems doable) items that need improvement. The three that get the most votes are the ones that the team will work on during the next sprint. Sometimes these require external help, and when that’s the case the team needs to assign a member to seek it out.

Bad Retrospective Smells

A subset of “bad scrum smells” is that whiff of an ineffective ceremony at the end of each sprint. Here’s what we mean:

  • The team raises the same “what went wrong” items sprint after sprint. This team is going through the motions of the retrospective, but not actually focused on continuous improvement. They’re not trying to fix the top problems. They should include tasks in their planning that touch on the items to improve. For example, if they’re failing to comply with some part of their definition of done, put a “confirm DoD” task on every item in every sprint until it becomes habit.
  • Many of the “needs improvement” items are external. A team that blames others for their problems is not taking ownership of their work and their process. Items like “The requirements were bad,” “system engineering didn’t keep our build machines up,” “the SME wasn’t available enough,” are all legitimate issues that a team might face, but in their retrospective they should be stating them as challenges that they need to solve. They could be stated as “We need to focus more on pre-sprint backlog refinement,” “we need to check the build machines every evening and get a ticket in to system engineering the moment we see a problem,” “we need to make some standing appointments with the SME rather than calling her ad hoc and not reaching her.”
  • Some team members “pass” on every round. If one or more members aren’t offering observations about problems, something – or someone — is suppressing them. It can be difficult to identify the root cause of non-participation in the retrospective. Whatever it is, this team is destined to never achieve high performance, so intervention is critical.
    • Is the moderator neutral? Does the moderator (or scribe if it’s a separate role) edit the team members’ contributions, or write them down as stated? It’s okay for the moderator to ask “do you mean the same as what Joe said a minute ago?” and if the answer is “oh yeah, he did say it,” then no need to duplicate. But if the answer is “no, I meant…” and the team member provides differentiation, write it down. It is never okay for the moderator or scribe to say “I don’t agree with you” and not write down the team member’s contribution.
    • Is a manager in the room? This is a peer review. Reduce attendance to just team members. Some agilests consider the product owner part of the team. The product owner passes judgment on the team’s work, so he’s not a member of the team. If the team has concerns about their relationship with the product owner, they need space in the retrospective to expose and discuss them. Leave it to them to invite the PO in, or not.
    • Is someone a bully? Is there a team member with strong opinions who manages to dominate even though the moderator tries to run a balanced meeting? If this happens repeatedly, other team members will give up and stop participating. If you see this, it may be necessary to address the behavioral problem through the person’s manager.


The results of the retrospective including all items raised (good and bad), and the top three items to improve, need to be documented where the team can see them. At Streamline our developers live in TFS, so that’s where we capture them. Each retrospective is documented in a work item assigned to the sprint. All team retrospectives are visible to everyone, and they’re immediately accessible without having to leave the development tool.

We don’t package them into the next sprint so that the team can plan tasks for the items to improve. But that might be an effective way of helping teams remember to act on them. We’ll report back here if we take that step.

Ceremonies: Kickoff and Sprint Planning

In this second post about Streamline’s ceremonies we look at the start of the sprint. Kickoff and Sprint Planning are standard scrum ceremonies that set the stage for the next two and a half weeks of work.


Sprint Kickoff

Kickoff marks the official start of each sprint. At Streamline our product owners identify their team’s complete sprint package at the start, rather than simply setting the team loose on an ordered backlog to do as much as they can. This practice developed out of a need to make commitments to stakeholders at the sprint level. While we’ve managed to reduce the need for that level of delivery granularity, we still follow the sprint package practice so that we can set stakeholder expectations.

The Product Owner “owns” the kickoff ceremony. In addition to the team, he invites any stakeholders who he thinks will be interested in the content of the sprint. This includes other teams, SMEs, perhaps people from marketing or sales, even, just possibly, a client representative. In order for this to work, each team’s kickoff has to be at a different time. We have a set schedule for these ceremonies as well as daily standups and product demos to ensure that any stakeholder can be at any ceremony without overlap.

We schedule thirty minutes for the sprint kickoff. Sometimes they take less time. The Product Owner presents each of the items packaged in the sprint. This is usually a mix of user stories, small changes, and bug fixes. The PO provides priority on the items. Sometimes a bug fix is the most important item, sometimes a quick change will deliver the most business value. The product owner also delivers the sprint goals, and clarifies which items in the sprint will be included in the Solution Demo at the end. Every item will be reviewed with the product owner when it’s done, but only items with high visibility and business value are demonstrated to stakeholders.

The team members can ask more questions about the items during kickoff. They’ve all see these items recently, since they’ve refined and estimated them within the last couple weeks. Nevertheless, questions do come up and sometimes conditions of acceptance are further refined. Stakeholders can and should ask questions to make sure they understand the scope of what’s going to be delivered.

When all questions are addressed, the PO asks the team for a vote of confidence (0 to 5, or “fist to five”). As during PI Planning, if confidence is less than 4 discussion ensues and, if necessary, scope is adjusted until all 4s and 5s are achieved.


Sprint Planning

Immediately after the kickoff, the team starts Sprint Planning. They shoo everyone else out of the room and begin by calculating their capacity in hours for the sprint. Our tooling (Microsoft Visual Studio) allows each person to put in their days off and their availability per day, then calculates the teams’ total capacity in hours.

Next they open up the highest priority item and review the conditions of acceptance once again. They start identifying the tasks needed to complete it. Some tasks are standard: Create the test plan, execute the test plan, design and implement the code, capture emergent requirements, update the database, prepare for the demo… They estimate each task in chunks of hours (see Estimation), combining small tasks so that the smallest chunk is three or four hours, or half a day. They work their way through each of the items in the package, identifying and estimating as much of the work as they can.

The planning meeting should not take more than 2.5 hours – or about one hour per week of sprint. If it runs long the team is probably getting into design discussions that should be tabled for later. If it runs much shorter, either they’re very good, or they’re not going deep enough – you can tell which as the sprint progresses.

One thing that sprint planning does not include is work assignment. Certainly there will be tasks that are an obvious fit for one team member or another, but nobody assigns anyone to anything during planning.

When they’re done planning, if the team’s planned hours exceeds their available capacity they need to speak to the Product Owner. Maybe they’ve over-planned or gold plated. Or maybe the process of analyzing an item has revealed more complexity than they realized before. The Scrum Master and any members of the team who are interested meet with the Product Owner to find ways to reduce the overall sprint package. They might reduce the scope of a large item by removing some of the conditions of acceptance, or they might remove an entire item from the sprint.

At Streamline we have a deadline of the end of the day after the start of the sprint for teams to renegotiate. This is to ensure that they get their planning done early enough to try to prevent disaster. It does not preclude them discovering complexity later in the sprint and renegotiating with the Product Owner then.

Ceremonies: Planning Increment Planning

Streamline Health takes its scrum and Scaled Agile Framework ceremonies very seriously. Adherence to norms and best practices by everyone involved helps our development machine run smoothly from sprint to sprint, release to release. While we try hard to give our smart, dedicated engineers the freedom to problem solve, innovate, and enjoy their work, we expect them to participate and be committed to a specific set of ceremonies.

That’s right, ceremonies. Not meetings.

Meetings are boring affairs designed by someone to meet a need that’s important to them. Agile is all about collaboration and meeting team needs and goals. Meetings, to the agile team, are so five-minutes ago.

Ceremonies are about recognition, achievement, and a little bit of showmanship. Let’s take a moment to recognize our success and share it with our stakeholders. Let’s focus for a few minutes on how our collaboration is going and how we can improve it. Ceremonies are interactive, and they are essential.

In the next few posts we’ll describe the ceremonies that we rely on to move our work forward and out to our clients.


Planning Increment (PI) Planning

PI Planning is a Scaled Agile Framework ceremony designed to align all of your teams at regular intervals. The goal of a planning increment is always a software release.

The key word in this cycle is “planning.” We plan for the next four sprints, with the goal of a minor or major release at the end. As the planning increment proceeds, the teams for a given solution might identify a need to do a mid-cycle release. That’s okay. And sometimes you plan to do incremental small releases each sprint. What matters is that you made the plan and everyone was informed, so as you deviate, everyone knows you’re doing it, and why.

The deliverables from PI planning are refined features, refined and estimated stories for the first sprint for each product, and identified stories for the rest of the sprints in this PI. Included in this is determination whether a feature is too big to complete in one planning. Dependencies are identified and, if possible eliminated. Architectural needs are also found and added to the plan through the creation of user stories for them. Perhaps most importantly, we determine how much of our capacity to allocate to each product. If a product has six sprints of must-do work, then we need to put two and a half teams on it. This is where those corporate goals and initiatives come into play. We have four teams, but five products, so we can’t go full steam ahead on all five during every planning increment. Which products get the focus is based on corporate initiatives.

That’s an Expensive Ceremon!

Everyone in the development organization, plus SMEs, participate in PI Planning. At first blush, it looks too expensive – in fact, we did not immediately implement it when we adopted the Scaled Agile Framework. We could not justify spending that much time every fourth sprint when some of our product teams were struggling to close functionality gaps that clients were screaming for. As we improved our product quality and made our development plans more transparent, the need to regularly coordinate work across teams emerged. Our senior management embraced the opportunity to set the direction of development and have their goals enacted. Suddenly it was worth it to stop and look ahead for a few hours every fourth sprint.

Making the Plan

Prior to the PI Planning ceremony the requirements teams develop high level business requirements and refine them into features. These requirements represent where the organization wants the products to go in the next three months. Input from all stakeholders – from sales to support – is taken into account. By the time of the ceremony, we have five plus or minus two features for each active product, with one or more user stories, conditions of acceptance, and technical notes. The product managers have determined their priority, and also taken a stab at high level estimation (t-shirt sizes). We have no features for products that are not currently in corporate focus. We will continue to support those products by fixing troublesome bugs and even do small enhancements that will delight existing clients, but we won’t allocate much bandwidth to them.

Day One

Everyone in the Innovations organization is included – every coder, tester, intern, documentation specialist, business analyst — everyone. We have two offices and some remote people. We set up video sharing in a large conference room in each office. If a remote person wants to turn on a camera they’re welcome to as well. The ceremony is scheduled for half a day.

We kick off PI planning with a brief keynote from our VP of Innovations. This keynote recognizes successes from the previous (actually, current at that time) planning increment and includes any recently closed big deals and any that are imminent. The idea is to place our ultimate goal – selling software – at the forefront of everyone’s mind as we dive in.

Next each scrum master provides a short update on her team’s big wins in the last planning increment. He also introduces any new members and announces any other changes of that nature.

The product managers then each present their proposed roadmap for the coming increment. No matter what product a team usually works on, they hear about it all.

Once everyone has an idea of the plan, the teams break out by product to dig in on the features. One of our teams has, so far, only worked on its main product. The other three have all worked on a main product as well as our newest rising star. So two or all three of those teams will break out together to look at the features for that product. If there are features for their other product as well, then they’ll allocate some time to those during this first day as well.

As the first day winds down, the product managers start asking the teams whether the plan is feasible. We ask them to come up with sprint estimates (see Estimation) on the features. We ask them for a vote of confidence on the success of the planning increment. At this point it’s still a little early to know for sure, but a very low confidence now will send the product manager back to the drawing board to look for ways to reduce scope before day two.

Executive Review

We spread the two halves of PI planning out so that there’s time in between to fix issues with the roadmaps that the teams have raised and to hold the executive roadmap review. The product managers present the roadmap as revised from day to our executive stakeholders. We ask for approval to proceed with this plan. Sometimes an emergent client concern can disrupt the roadmap at this point. The product managers try very hard to be aware of the potential for this before getting to this stage, but it can still happen. We’re agile, right? We love change.

Day Two

The video is back up and lunch is on the company as we gather to go deeper on the features and stories. The teams decompose features into stories and draft conditions of acceptance. They haggle over details of scope. They think about the “how” and argue over architecture and design. Product managers and other leaders continually moderate to pull them back out of the weeds when they start slashing and hacking with their .NET and C# and Machine Learning machetes.

Once again, as the half day winds down we ask for a vote of confidence on the planning increment. By now the teams should have a very good idea of how the work will be spread out over the next three sprints and whether it is achievable. But as before, if we don’t get fours and fives we discuss and adjust.

The final stage in this long ceremony is a retrospective on the event. Everyone is able to analyze any aspect of the event, from the duration to the food to the progress that was made. We look for items to do better next time. We’ll talk more later about retrospectives in the entry for that ceremony.


PI Planning occurs early in the last sprint of the previous planning increment. This gives us time, once the dust settles and the rooms are tidied up, to clean up those hastily written requirements. If a team used index cards or sticky notes, someone has to transcribe them into our system. There might have been requirements questions that couldn’t be answered during the ceremony, so our requirements folks get to work finding answers.

PI Planning doesn’t completely replace incremental backlog refinement. It kick starts the first sprint and informs the entire increment. More importantly, it instills a larger sense of purpose in every member of all the teams, and creates visibility across the portfolio.


“It’s better to be roughly right than precisely wrong.”

-John Maynard Keynes

What do all of these have in common?

  • T-Shirt Sizes
  • Sprints
  • Story Points
  • Hours

Answer: They’re all estimation scales used in Streamline’s application development lifecycle.

Streamline Health’s development teams employ each of these different levels of granularity for estimation at different phases of the lifecycle. Appropriately accurate estimates are key in all phases of our lifecycle, from figuring out how long it will take to achieve the software development part of an organizational goal all the way down to sprint planning by a single team.

From the highest level, earliest phase down to the last days of a sprint, that Keynes quote up at the top holds true. If you strive for accurate estimates you’ll quickly encounter the law of diminishing returns. You simply can’t accurately estimate work that you don’t fully understand (yet). Spending time early on to gain the necessary understanding will take nearly as much time as simply (or not so simply, which is the problem) doing the work.

Our increasingly more granular scales is Streamline’s approach to avoiding “estimation paralyses.”

It’s important to understand that our agile estimation techniques are not intended to produce quotes for clients. We are not directly selling our software development services. Agile estimation at Streamline is used for planning and capacity management.

T-Shirt Sizes

Our earliest estimation scale, for when we’re thinking about the next quarter (“Planning Increment”) in broad terms is simply small, medium, large, and extra large. When we use these, we’re talking at the “feature” level: work for a single product that will take more than one sprint to complete. A “small” feature is one that could be completed in a couple sprints with capacity left over for other work. Medium will take two to three sprints and Large will take most of the capacity of one team for the entire planning increment. An extra large feature is one that we don’t think can be completed in four sprints (one planning increment) by one team. T-shirt size estimates are assigned by the product management team with expert advice from architecture, engineering, and other SMEs.

Sprint Estimate

When we start trying to shoe-horn features into a planning increment, we move to sprint estimates. How many sprints would this feature take if it were the only thing that one team worked on? Yes, this is pretty similar to the t-shirt sizes we started with. Sprint estimates are not as intuitive for senior management to understand, so the t-shirt sizes are something a proxy for sprints designed for stakeholder consumption.

The sprint estimate is not about actual calendar/sprint time. We would never package all of the stories for one feature into one sprint after another with no other work for that team. We can’t — there are always competing priorities.

Sprint estimates are done by the scrum teams and stakeholders during our quarterly planning increment planning session. After the teams have had an opportunity to review and refine the proposed features they’re asked to estimate them in sprints. By this time they have an idea of how the features will be decomposed, so their estimates are more granular than the t-shirts, if still quite rough.

Story Points and Ideal Developer Days

Story points are a very standard way of estimating user stories and other sprint-level work items (including bug fixes and small changes). The intent is to keep the teams from diving into hour-based estimates that would tempt them to try to decompose into tasks. Getting engineers to accept this practice is one of the most difficult aspects of an agile transformation. These people are detail oriented and precise, and story points feel sloppy to them.

The introduction of the Ideal Developer Day Story Point is intended, among other purposes, to help them get used to estimating in the abstract (by making it less abstract). An Ideal Developer Day is however much work a typical team member gets done in a typical day. It’s difficult for developers not to ask “how many hours is that?” which leads to further decomposition. We counter those questions with “just use your gut — how many days do you think you’d spend on your part of this story? How many days would your colleagues in the other disciplines take? Yes, you do have to include their work in your estimate. You’re a team.”

For story point estimates we use the Fibonacci sequence. This ever-growing series of numbers forces larger chunks of work to have proportionally higher estimates. This enforces the notion that you don’t know what you don’t know, and builds in the extra time to learn about the unknown. It also eliminates arguments like,

“It will take four days!”

“No, it will take five!”

“I think it will take six!”

Just pick either five or eight and move on.


Finally, once the stories are packaged the sprint is kicked off, the team plans their tasks using estimation in hours. But we still limit the granularity: The minimum is a half day (three or four hours), with half-day jumps after that. So tasks can be four, eight (a full day), twelve, or sixteen (two days) hours. The next value would be twenty-four, but we discourage teams from creating tasks that large because, frankly, it means the don’t really know how large it is.

This is another tough concept for engineers to accept — breaking up what they consider one long task into one and two-day chunks just so that you can call parts of it done. But it’s an important practice that helps the team see progress on their task board, also identify incorrect estimates sooner, and intercede when a team member is having a problem and not admitting it. If a task was planned to take three days, and on the third day the team discovers that the person working on it really hasn’t made two days worth of progress, they’ve already lost a full day that they could have used to fix the problem.


The estimate just be provided by the team that is going to do the work. At the feature level, sprint estimates might be done by a gathering of multiple teams. At the story level, if you aren’t sure which team will do the work, get them all together to estimate, or if you change the team assignment, have the new team re-estimate. It’s critical that the team doing the work owns the estimate.

For sprint and story point estimates, we ensure that all those voting agree to the result. It is important to emphasize consensus on estimates done by a team so that nobody on the team can later say, “well, Ted and I voted thirteen but the three people who voted five won. I knew we wouldn’t get the work done.”

To prevent an estimation session from devolving into a design session, or a riot, we follow a three-vote process. After the product owner presents the story or feature, the team can ask some questions and might even do a little more refinement. Then they’re asked to vote. If the vote is not unanimous — if even one person differs — we set a two minute timer and ask someone with a high or low vote to try to convince the others. If there’s still time in the two minutes for someone else to state an opposing opinion they can. After two minutes the team must vote again. We repeat this process until three votes are taken, and only then do we take the majority.

The teams can use this process during planning if they’re having trouble gaining consensus, but we generally find that a mature team can reach agreement over task estimates without the formality.




Agile Functional Requirements Model

Your team is humming along, producing sprint after sprint of working code, continually expanding your software application with great features that your clients love. Then one day during a backlog refinement session someone asks, “What’s the maximum length for a user-defined report name?”

You all look at one another and shrug. Then someone says,

“I don’t remember, was it in the user story?”

“Maybe. When did we do it? What sprint?”

“Two sprints back? No, three. I remember it was hot out.”

“Can’t be, we haven’t touched user reports in months. You’re thinking of dashboards.”

“Oh, right.”

“Was the maximum even in the acceptance criteria?”

“No, it wasn’t. I remember we had to ask the product owner during the sprint.”

“So the story won’t have it, even if we do find it.”

“Somebody log in, create a report, and try really long names until you find the limit …”

You’ve just run up against one of the drawbacks to agile methodologies: valuing conversation over documentation means you sometimes don’t write down things that you’ll need to remember much later.

There’s no question that the focus on business value delivery, the elimination of big requirements up front, and decomposition into small demonstrable chunks, are all advantages to agile requirements that can improve a team’s success. But when you’re building a big system over a long period of time, you need more than memory and a pile of completed user story cards as documentation.

A continually maintained functionally organized requirements model bridges the gap between business-oriented user stories and technical design documentation (assuming you’re creating and maintaining those). It can be used by your requirements team for impact analysis, and it can be a crucial part of your trace matrix. With proper linking you can generate metrics around functional test coverage, development by persona, and other measures of your product.

Maintaining a requirements model iteratively does not add a great deal of work to each sprint. And that’s key – requirements are not added to the model until the work is committed to a sprint. During the sprint, the team (usually a business analyst, but on a truly cross-functional team any member should be able to do it) adds the requirements for each item in the sprint to the model. The user story becomes one or more business requirements, the acceptance criteria become functional and non-functional requirements and business rules. The team identifies and documents any additional requirements that weren’t part of the conditions of acceptance – like that maximum field size for report names.

When creating test cases, the team creates links between the tests and the requirements. Even if you work with an IDE (Integrated Development Environment) that automatically links test cases to user stories, you will derive value from linking the tests directly to the more granular requirements. The team will be able to tell immediately if their test plan is not covering part of the functionality. They will also see other requirements related to the functionality that have already been done, and the test cases linked to those. This supports test case maintenance and reuse.

Organizing your requirements functionally makes it easier to find requirements, and allows your requirements team to see new requirements in context. You will be far less likely to specify a new feature that contradicts one you built six months ago if, as you’re analyzing the new requirement, you have a look at the model and see the earlier requirements.

Breaking out requirements by type: functional, non-functional, business rule, business requirement, and perhaps others allows you to trace from most technical/granular up to least. You can look at a top level business requirement and see all of the functionality linked to it that a change might impact.

Isolating non-functional requirements is important because, at least in a Scrum process, many of them are not stated as part of the user story and conditions of acceptance. They are applied to all work by the team as part of standards and definition of done. Likewise, the non-functional requirements in the requirements model should be derived from standards (e.g., your user interface standard, your performance standards) and will change less frequently – unless you’re redoing your user interface, improving performance, or focused on some other area related to quality. What must happen each sprint is linking of new functional requirements to related non-functional requirements.

And finally, business rules should be isolated because they often can change without impacting functionality. Changing the allowed length of that user-defined report name should not mean changing all the code having to do with defining and naming the report – just the validation on its length.

If you’ve scaled your agile process and have more than one team working on the same software, the shared requirements model is a critical tool to help them keep track of the state of the system as they go. Imagine if the team doing the grooming at the start of this blog entry didn’t even do the user story that created the report name function?

Software is for People

When you empower your software development team to make decisions about the details — and in case you hadn’t noticed, that’s one of the core principles of agile practices – you must also supply them with an arsenal of tools that help them make the right decisions. Understanding who will use the software they’re building is one such tool.

But it’s not good enough to just say, “we’re adding this feature so that people can draw on their photos.”

One engineer might post a lot to sites like Reddit and Quora, so she thinks “redact license plates and faces. Got it!”

Another is a visual artist and thinks, “Select areas and add colors, blend, maybe some stroke filters…”

A third is all about Instagram and thinks, “funny filters and stickers! Let’s find some libraries to offer.”

Certainly by the time the item has gone through refinement you’ve set this team on course for the right kind of drawing. But why not save time and establish the intended use more clearly from the start by telling them what kind of user the feature is for?

A persona is an aggregated biography of a certain type of user of your software. Each persona should be based on real people in the role that they represent, which can be derived from market data about the slice of the population that has that job title or role. Personal details like age, gender, home life, marital status, hobbies, and geographical location should all be derived from market demographic data. Even more importantly software usage details must match the role that the persona represents.

Does all of that sound more like marketing than software requirements? It should. Personas are a standard marketing device. And it also should because you’ve most likely got to sell your software to that same market. If you aren’t building your software for your market, why are you building it?

So let’s write a user story for that photo drawing requirement:

“As Raul the frequent social media poster, I want to obscure parts of my photos so I can post them on public forums without revealing any personal information that I don’t have the right to and earn ‘likes’ or ‘karma.’”

You just eliminated a half hour of debate over the scope of the item. Redacting license plates it is!

Giving the persona a name and a biography puts real people in the minds of the team members. You know your team is maturing when you hear them referring to your most common personas by name.

Identifying the persona that each requirement is for helps you keep your product focused. If you can’t figure out which persona wants the requirement, perhaps you shouldn’t be doing it at all. If you have requirements for a legion of personas, you’re probably spreading yourself too thin. Most of your requirements should be for a single, primary persona. Try to satisfy more than one and you’ll end up satisfying none.

At Streamline we have a sizeable inventory of personas because we’re actively developing four software products (which have sub-products with different user types). The personas are a common resource – some of them use more than one of our products. A great example is Dorothea the user administrator. She’s a busy lady, handing user accounts for all of our products!

Dorothea is one of our “secondary” personas – others include technical support analysts, implementation engineers, and report writers. These are not the main roles that we build software for, but they do interact with our software in very specific use cases.

Roles we do not have personas for are the Product Owner, the Scrum Master, the chief architect, and other engineering management type roles. Why not? Well, are we selling our software to those people? No.

I once had an inexperienced business analyst argue that the scrum team’s work was going to be judged by the product owner, so the user stories should be written from the product owner’s perspective. Yikes! The product owner is just a conduit for other stakeholders’ requirements. This attitude smelled of the command-and-control culture that our organization was trying to overcome at the time (and largely has). Watch out for this kind of perturbation of the intent of agile practices — they can slip in when you aren’t looking!

We recently gathered data for requirements by primary and secondary persona for each of our products. One of them has been doing as much for secondary personas as primary personas, and one has done more for secondary personas! When we drilled deeper we found out why: we’re commercializing one, and fixing data infrastructure for the other. But if we couldn’t lay our finger on these reasons, we’d need to take a good long look at those backlogs as related to our company goals. (You’ll note that I’ve used that redaction feature to obscure the product names.)

How would this metric look for your products?