The one place in the company where the push to expand beyond kittens has been strongest is from the sales department. Some members of the sales team have felt that their ability to grow the market has been hindered by the fact that they can't target companies looking for puppy-related content.

Recently, the head of sales sat down with one of the company's largest clients, a multinational marketing conglomerate, and learned that they were planning to switch contracts to a competitor of WithKittens over this question. The following excerpt from an internal sales memo highlights the issue:

This memo catches the attention of the company founder, who reluctantly calls in the product owner for a meeting. Among the issues they discuss are the value of adapting to changing market expectations, and the appropriateness of adding a service that conflicts with the historical intent of the company—not to mention the company name.

Together they decide they need to do some work on puppy-friendly features—if just to figure out what it might take to support puppies in addition to kittens, given their current infrastructure. Among the critical issues they feel it's important to keep in mind are the overhead of maintaining an entirely independent service, versus the cost of developing and supporting an integrated service.

Because of the urgency of the sales memo, they decide this is a high enough priority that it has to bump their critical seasonal push to integrate the new Persian and Angora kitten promotion for the holidays, which the team is scheduled to work on next. The product owner goes back to the head of product with the details of that discussion, and receives approval to make that change to the prioritization.

With a fresh mandate, the product owner goes back to the product backlog, where all future ideas for the service are tracked. It's almost painful to push some of the other high-priority ideas down on the list, but it's clear this is going to have to be done first.

After a day or two of research on competing services, the product owner pulls together the details of the idea. Most of the other services put the animal choice late in the process for customers, almost as an afterthought. Following that approach, if they are going to offer customers the choice of puppies as well, instead of just kittens, that will require a major adjustment to the core product, as well as a new interface element.

There are only one or two other services that focus exclusively on one type of baby animal. For the most part, they are small and haven't gained the market traction that WithKittens has managed to achieve. But despite the potential for fragmenting the market, there is an advantage to being able to stay focused on kittens on their core service. It also avoids the confusion of adding puppies on a service called WithKittens.

Ultimately, the product owner decides the best approach will be to ask the team to clone some sections of the WithKittens service, and create a minimal parallel WithPuppies service. They have already purchased the domain WithPuppies.com in anticipation of this possibility, and the designers have been playing with ideas around this concept casually.

Before moving forward with that decision, the product owner calls one of the senior engineers in for a chat, and confirms that this would be the more technically straightforward approach. The sooner they can get a service into the market that they can test, the sooner they'll know whether or not it makes sense.

After sketching out a few ideas, the product owner decides the best way to do this quickly and efficiently will be to create a scaled down version of the product exclusively for web users. The company can use its deployment testing system to limit the audience to a small percentage of visitors.

These visitors will be presented with a link that offers to show them puppies instead of kittens as soon as they log in. If they click that link, they'll be taken out of the WithKittens.com domain and put into the with WithPuppies.com domain. There, the experience of the site will be the same, except kittens will be replaced with puppies.

Since this isn't what most customers came to the company for, it will have to be very easy for a visitor to switch back to kittens. It would also be great if they could include a way to gather feedback from visitors.

The product owner checks the queue of projects the Design team is working on. Design is set up under a kanban process, so it will be possible to slot in the new design story to start immediately after the designer finishes whatever is currently being worked on.

After sitting down with the designer and discussing some of the visual and user experience issues implied by converting the site from kittens to puppies, the product owner creates stories for design around changing image elements and kitten-specific cues in the content creation path of the application. There will need to be some copy changes as well, and for the sake of this test, the product owner will write those.

The designer agrees that there won't be much need to change the overall user interface. There is already a feedback gathering tool that they can skin for this purpose, as well as an alert banner format that can be used as a trigger for visitors who want to convert back to kittens from puppies. Other than that, it will just be a matter of populating a database with appropriate puppy images, and adding subcategories to the existing menus.

The designer confirms that it shouldn't be necessary for all the design elements to be completed before the engineering work starts, because the specifications for the image content and the text changes should be driven by the standards already in place for the site. As long as the changes stay within the parameters that already exist, this work can probably be completed within a single sprint from a design perspective.

There are a few ways to break this feature apart, but the product owner doesn't want to get into the weeds of trying to do the work the engineers are better at. The goal is to stand back and view this as a feature from the user's perspective. How would a user who wants puppies instead of kittens take advantage of this feature?

The best way to describe what will be needed—in terms of stories the team has worked on before—is by creating additional pages in the content creation flow. These pages will be skinned versions of existing pages, with different options presented. They will use the existing alert and feedback features, and will only be triggered for a percentage of visitors.

Thinking this through, the product owner can anticipate some of the questions the engineering team will be likely to ask when presented with this story. The acceptance criteria for the story will need to be specific about what percentage of visitors will be tracked to this new experience, and also provide information about the availability of design and copy changes.

The product owner writes up the following story to present to the team, describing the new puppy feature:

Some of the main acceptance criteria for the story go like this:

"So how is this going to affect the experience of the rest of the site?" the first engineer asks. "I see that the user who's chosen to see puppies will only see puppies on this particular page, but what about on the rest of the site?"

"The scope of the changes will be limited to the pages being changed," the product owner explains. "That means the test users might experience a visual disconnect when they leave these pages and navigate to other parts of the site, such as the billing and confirmation pages. After all, we've got a lot of kittens and kitten-related themes running through all the pages. But it's out of scope to make broader changes to the entire site just for this test."

"Is there something else we can do?" another engineer asks. "We have the alert only on these pages. Can we have them on the rest of the site as well?"

"I'm worried about making changes that will affect people not involved in the test," the product owner says. "I don't want to make this any bigger than it has to be, and I certainly don't want to put the stability of the site as a whole in danger."

"I don't think it would be that hard," the engineer goes on. "We already have the ability to turn on an alert that can be shown on every page of the site. Remember, we did that during the last holiday promotion."

"Can we make sure this will be limited to the people who opted in?" the product owner asks.

"Sure, that won't be a problem," the engineer replies. "In fact, we could even make it so that the people who are selected for the test could opt in later, if we wanted to."

"I don't think that would be necessary," the product owner says. "Let's try to do this as simply as we possibly can."

In the end, the product owner decides that it's sufficient if visitors who have opted in to the puppies retain the alert about the puppy beta at the top of the page as long as they are in puppy mode. It will be there to remind them that they have selected puppies instead of kittens, despite the strongly kitten-oriented messaging on the rest of the site. That change is added to the acceptance criteria, which now include a line looking like this:

At this point, another engineer points out that visitors who have selected puppies, and created content using puppies, could lose what they have created if they opt out elsewhere on the site.

"It depends on how we implement it," another engineer says. "But it'll be awkward to keep the custom elements available for people who have opted out of puppy mode."

"What do folks think would be easiest?" the product owner asks. "Should we try to retain mixed content, or should we force people to delete custom content if they disable puppy mode?"

After a little bit of discussion, the team decides that the best solution to this will be for the opt out link on the alert to take people to a page warning them that any puppy-related content they have created in that mode will be lost when they opt out. This will be an inconvenient but appropriate action for that page during the beta, regardless of whether they've arrived there from the content creation section, or from elsewhere on the site.

To handle this, the product owner changes the acceptance criteria around the opt out link:

"Does that look good to everybody?" the product owner asks.

There are nods of agreement from all around the table. One or two of the engineers say "Yeah."

"Great!" the scrum master says. "Let's vote."

The team has chosen to use a modified Fibonacci scale to estimate points. That means relative estimated points for a single story can be one, two, three, five, eight, thirteen, or twenty. Everybody on the team has a deck of cards with those numbers on it, and when the scrum master calls for a vote, each of the engineers shuffles through and picks the card that represents the amount of effort they think this task will take.

"We've got five thirteens and one twenty," the scrum master reports. Historically, this team assigns twenty points to stories that they don't believe can be completed within a single sprint. Even thirteen-point stories are questionable. "Do you want to tell us why you think this would be a twenty?"

"It seems to me like there's a lot of unknowns," the engineer who voted twenty says. "This is the first time we've tried to do something like this, and I know our database is pretty tightly integrated with the whole kitten concept."

"Yeah, you've got a point," one of the other engineers says. "We've been talking about re-factoring out the kitten terminology for a long time, and it's never been a high enough priority for us to get to it."

"Do we really need to do that in order to make this happen?" the product owner asks.

"The code is going to look really ugly unless we do," the first engineer replies.

"I get that," the product owner says. "Is it bad enough that we can't do it just for a test?"

"It's just frustrating that we don't get a chance to re-factor these things when stories like this come up," the first engineer says. "We've been talking about this technical debt for months, and we all know it has to be addressed at some point."

"I hear you," the product owner says. "I do understand we need to make some time to clean things up. I'll support making that the next highest priority in the next sprint after we get this completed. Can the team write up a chore for that, so we can keep track of it and not keep pushing it down to the bottom of the pile?"

"This story would be a lot easier if we did that refactor first," the engineer says, grimly.

"I understand that," the product owner says, "but we don't have that luxury right now. If we can get this prioritized, maybe the issues that come up as we work through this story will help define how the refactoring needs to go. Is that a possibility?"

The engineer shrugs. "We'll see."

"OK," the scrum master says, "can we agree to move forward with this story as a test—if we get the assurance that the re-factor will be the next top priority after that?"

"I can agree to that, I guess," the product owner says.

The engineer nods, and the scrum master goes on, "So does this still feel like a thirteen to everybody, given what we just talked about?"

"I don't think the code'll be bad enough for a twenty," another engineer says. "We can stick it in a separate branch, and use explicit naming conventions. As long as it's tagged properly, it'll be easy to back out."

"Then I guess I can go with thirteen," the first engineer says.

"Great," the scrum master says. "Then this is a thirteen, and we still need somebody to take responsibility for writing up the re-factoring chore."

"I've got it," the first engineer says, still frowning at the product owner, who nods in agreement. "And I'll be sure to bring it up at the retrospective, to make sure we commit to it like we agreed."

The product owner doesn't have any new stories to introduce other than the one about the puppies. That makes establishing a prioritized sprint backlog much easier. Using the team's numbering convention, that story is labeled 11-1.

There are a couple of stories that haven't been completed in the previous sprint, and one that's still in QA. The product owner decides it's more practical to let the engineers working on those stories to finish them instead of pulling them off and making them work on the new story first.

The sprint backlog includes all the points for the stories that weren't completed the previous sprint, along with the new thirteen-point story. The total goal of 24 points is a little high, given the team's previous velocity average of 18. But in this case that total includes several points from stories already partially completed, so the team agrees that it is feasible.

The engineer who argued that the puppy story should be estimated at 20 points plans to set aside time to write up a chore for the refactoring that's needed, so it can be introduced as soon as possible.

Once the sprint backlog is complete, the scrum master makes sure that everybody in the team agrees to it, and that the product owner will be satisfied with the product increment represented by those stories. Then, with everybody in agreement, the scrum master launches the sprint.

Here's what the sprint backlog looks like at the start of sprint eleven: