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

Advertisements

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.

STRMMeltingSnowmanKICKOFF

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.

STRMMeltingSnowmanSPRINTPLANNING

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.

STRMMeltingSnowmanPIPlanning

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.

Charge!

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.

Estimation

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

Hours

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.

Norms

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?

Backlog Management

Agile’s Dirty Secret

Agile purists sometimes seem very proud of eliminating “requirements” from the software development process. The thing is, they haven’t. They’ve just rebranded requirements as the “product backlog.”

A team can’t successfully build anything without a plan, and that’s what the requ — uh, I mean backlog — is. At Streamline we use three tools to manage the backlog through its entire lifecycle:

  • Aha! — a product management tool for capturing and forming ideas and product strategy and refining into features.
  • Microsoft Team Foundation Server/Visual Studio — for the granular management of user stories. Because we’re a Microsoft shop, the MS development environment is the best tool for the team to manage their daily work, from user stories to tasks to code change sets.
  • IBM Rational DOORS — for the functional requirements model and more granular trace matrix. DOORS is a powerful, traditional requirements management tool that might not seem to fit in an agile world, but in fact serves as the backbone of knowledge about our products.

INVEST in Good Requirements

Scrum teams should not accept into their sprint package any backlog item that does not meet INVEST: Individual, Negotiable, Valuable, Estimable, Small, and Testable. Your process must include opportunity for the team to determine whether each candidate item meets INVEST, and the opportunity for the team to estimate the effort before the sprint is packaged. At Streamline we hold a couple backlog grooming sessions and a couple estimation meetings during each sprint to work on the items for the next sprint. While this draws the team away from the current work, it is critical preparation for the next iteration.

Just-in-Time and Trailing Requirements

When you’re building a complex software application that will continue to evolve over several years, it is important to keep track of decisions about functionality that are typically made during each agile iteration. If you don’t, you’ll be struggling to remember the intended sequence of steps in some process, or the business rule governing choices in a context-sensitive menu months later when you need to make changes.

Before agile, you would have turned to the massive requirements specification. But that’s the thing those agilists are so proud of eliminating. Instead, you’ve got all those user stories and conditions of acceptance on hundreds, maybe thousands, of physical or virtual cards to look through. What sprint was the original story packaged in? Did we do any other changes since then? Did the COAs actually cover this specific business rule that’s not making any sense now, or did we come up with the rule during the sprint?

Even if you maintain good metadata on your digital backlog (like, what area of the application the user story is for), and you are able to search for key words, the completed product backlog is still more like the pieces of a jigsaw puzzle — and if you’re under the gun to package an enhancement you’re not in the mood for games.

At Streamline, we believe in just-in-time requirements and maintaining a living functional requirements model. We manage the product backlog in the traditional agile way — high level features decomposed into actionable user stories with conditions of acceptance. Teams groom and decompose and estimate, and stories are packaged. We only specify enough for the team to know what to do. But here’s where we divert from the agile purists: during the sprint, the team also captures the complete requirements in a functionally organized requirements model. The conditions of acceptance are converted into traditional requirements (“The system shall…”), and additional requirements that the team identifies are also documented. Even if functionality is easy to understand by using the software, so granular requirements are not necessary, business rules can be opaque and are especially important to document.

During each sprint, the team also links their test cases to these requirements so that we can collect metrics on functional test coverage. The model supports a trace matrix that allows us to track from a bug through a test case to a functional requirement, over to a related business rule, and up to the original user story.

This functional requirements model serves as an analysis tool for future requirements. We can see all of the related requirements to the one we’re considering changing, as well as the scope of the test cases, and whether there are any existing bugs. The investment the team makes in the requirements model pays off for the product owner and business analyst preparing features and stories for future sprints.

Calibrating Business Value

When you’ve got five software products managed by five product managers, how do you know that they’re all using the same scale when they assign business value?

You don’t. At least, not if you don’t pay some attention to calibrating across the organization.

The other day we had a lively discussion as we looked at completed user stories from our various backlogs and the business values that they’d been assigned. Participants included not only the folks in backlog management roles (directors, managers, and business analysts), but also scrum team members and folks from sales, IT, and client services. It was a fantastic opportunity to show these non-development team members that engineers do want to deliver value!

Nobody in the room knew all about all of the products. But once we’d presented the fundamentals of how business value is used in scrum and a way to evaluate a story, most everyone reached similar values on stories that they understood. We explained our existing scale (zero to three hundred points in ten point increments), and then we suggested some criteria:

  • What percentage of existing clients want it?
  • Is it for the primary user persona?
  • Has it been validated through customer development?
  • Is it sizzle or steak?
    • Is it primarily to help sales close deals?
    • Is it a technical change that will retain existing clients?

Then we presented a series of examples and asked the group to assign value (see the image above). For some, consideration of the number of impacted users was a revelation. For others, abstracting business value by not somehow tying it to revenue was pointless. And for a few, accepting that solving our own problems, like improving deployment or fixing the logo on the home page, has no business value was really tough to swallow. Nonetheless, everyone left with a clear understanding of what those numbers mean on our work items, and the product management team is going to do better at calibrating their value assignments with their colleagues’. That’s a win.