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


High Performance Commitment Culture, Start with Team Norms!

What do the following have in common?

They are manifestations of team norms throughout time, driving organizational culture towards better performing teams.

Team norms are important for establishing a shared belief that the team is safe from interpersonal risk taking. Teams norms express intentions of individual team members as a collective whole. They represent an opportunity for individuals to express what is important to them and to learn what’s important to their teammates. Team norms pre-empt unforeseen situations by providing a context to proactively discuss grievances about team behavior and prevent frustrations from festering. They ultimately help establish trust among team members and optimize team performance.

At Streamline Health, when we form a scrum team, their first sprint is a “Sprint 0” during which they define their team norms. The practice may be applied more broadly to other teams to discuss and agree to norms at the beginning of an engagement. Team norms may be used as a tool to reset anti-patterns in a non-confrontational way. If people sometimes forget the norms or unintentionally violate them, having agreed to be governed by them enables team members to remind each other of the ideal behavior.

5188116378_57e6c4be1d_qUsing an analogy found in nature, team norms are the visible surface of an iceberg.  They should be documented and posted somewhere for all to see and refer to in times of conflict. There is also a large portion that lurks beneath the surface, the surface does not move without the hidden mass below.

At a macro level, according to various sources on Scrum Alliance, good team norms empower the team to deliver value at the end of the iteration. They do not define a role for individuals as the team is more important than the individual. They empower the team to take ownership for the work and each other. Good team norms also save the team valuable time, forgoing discussing the things that are regulated by them, and focusing on the work instead.


Norms can be at any scale, ranging from agreement about how decisions get made to basic principles about how the team communicates on a daily basis. Maybe the earliest recognized manifestation of team norms for software development, the Agile Manifesto (c. 2001), emphasizes that while there is still value in the items on the right, the items on the left are valued more. At Streamline Health the Agile Manifesto is the genesis of many team norms.

At a recent lunch and learn associates across the organization came together to discuss team norms and how they contribute to a high performance commitment  culture. We discussed specific examples of team norms that can address any aspect of the team’s functioning, such as safety, expected work hours, communication response times, or meeting attendance. Norms that address a team’s operating rhythm, communication, decision-making informed by a definition of done, and accountability can have a big impact on team cohesiveness and performance. We also discussed examples of good team norms that address individual team member’s egos, such as avoiding hidden agendas, being open minded, and admitting it when you don’t know the right answer. These are some of my own personal favorites. Team norms should not be set in stone and may evolve over time as team culture changes. Streamline teams are encouraged  to review their norms early and often and to use the sprint retrospective as an organic cadence to review and refine them.

Back to our nature analogy. If team norms are the visible surface of the iceberg, what  is  the portion that lurks below the surface? Culture. Culture is the critical mass that is strong enough to puncture holes in titanic ships. It often lies beneath the surface. Culture is what team norms require to be sustained over time and space.

In 2013, Google made this discovery: Who is on a team matters less than how the team members interact, structure their work, and view their contributions. Instead of stocking the team with individual stars, it’s more important to have empathetic team members who listen to others and can make the team greater than the sum of its parts. High-performing teams, they found, displayed five characteristics.

  1. Psychological safety

Members feel they can be vulnerable. They know their ideas and opinions will be respected and considered, even when they conflict with those of the rest of the team.

  1. Dependability

Members are confident their coworkers will deliver what they are supposed to when they are supposed to.

  1. Structure and clarity

Members understand their roles and the roles of others, and the goals of the team overall.

  1. Meaning

Members feel that what they are working on is important to them personally.

  1. Impact

Members believe what they are doing will have a positive effect on the organization and the world.

Google sales teams with the highest level of psychological safety outperformed their revenue targets, on average, by 17%. Those with the lowest psychological safety underperformed, on average, by 19%.

Another takeaway: the effectiveness of teams that were very high in dependability was actually impeded by a lot of structure in terms of role definitions and goals. By contrast, the teams with low dependability benefitted greatly from structure and clarity. That’s a useful insight for new teams, where members don’t yet know whom they can depend on.

According to their research, by far the most important team dynamic is psychological safety — the ability to be bold and take risks without worrying that your team members will judge you.

The High Performance Commitment Model posits that if we apply the elements of cross-functional, focus, purpose, psychological safety, trust, and transparency over time we may achieve a high performance commitment culture. Therefore, for a high performance commitment culture, start with team norms that enable these elements.


-Luis Lira, Manager of Business Analysis

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: 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: 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.

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.