Evil User Stories for Modeling Evil Users

If you’re like most Product Owners, you probably have a backlog full of user stories modeling just what you’d like to see your best users do with your product.

But what about your “not so great” users. Not just those who are casual users of your product, or approach it with the lackluster enthusiasm. No, I’m talking about those malevolent users who have set out to do you harm. You have those users, too…you just may not be thinking about them.

These are the users who have only dubious intent towards your company, your product, or even your other users. We call these users our “Evil Users”, and whether you want to think of them or not…they’re your users, too. And they deserve they’re own user stories.

The Choosers versus Users Dilemma

The Choosers versus Users Dilemma

We often talk about our “customer”, they’re at the center of everything we do. But we rarely talk about who our “customer” may actually be. Often, we just assume that our customer is the user of our product…but what if they’re not? It may seem strange to imagine a case where our customer and our user are not the same person, but it happens more often than you may think. But if our customers are not the users of our product then we need to think about who is…and how can we design a product that appeals to them, too.

For example, imagine that we create educational apps for kids. We write these apps to appeal to kids, and we want them to be fun.

Kids are our Users.

So, to appeal to our users we craft colorful environments filled with enticing audio cues and addictive rewards systems. And, as a result, kids love our apps.

But, kids aren’t paying for our apps…their parents are. So, we also need to appeal to the parents. In this scenario, the parents are our Choosers. This means that the app needs to provide more value beyond simply being “fun”. Perhaps it needs to provide educational value, or it simply needs to occupy the kids on a long car ride. Whatever the reason, it ultimately needs to serve the needs of the parents who will actually be the ones to spring for it.

But we can’t forget the kids, if they don’t enjoy the app then they’ll stop playing with it. And if they stop playing with it then they won’t be occupied on long car rides and their parents won’t buy apps from us again.

See what we did there? We’ve created a cycle. Whether it turns out to be virtuous or vicious is up to us.

Enough of This Consumer NonsenseThe Choosers versus Users Dilemma

I know what you’re thinking. Sure, that example is all well and good for consumer apps…but I build business products. I build products for the enterprise…I don’t have to worry about this nonsense. But what if I told you that your Choosers versus Users dilemma is even more pronounced.

Imagine that you’re building a CRM app for the real estate industry. You’ll want the the product to appeal to real estate agents so you’ll want it to be easy to use, lightweight, and provide useful information such as contact info and recent conversations that agents can draw on when interacting with prospective buyers and sellers.
In fact, we could even customize it to their industry to allow agents to quickly access additional information such as each prospect’s desired home type and school district.

It should be everything they could ever want. After all, they are our Users.

However, there’s just one problem. The agents aren’t paying for the product, the brokers who own the brokerages they work for are. And as much as the broker would probably like to make their agents happy, they’re not likely to spring for the cost of a custom CRM system just to put a smile on their faces. So we also need to appeal to them….perhaps even more so. They are our Choosers.

To make the system worthwhile to our Choosers, we’ll need to provide features that meet their unique needs. Many of these will likely stem from their agents’ ability to bring in new business and close sales, but may also include things like understanding the types of properties their agents are transacting (and what types are likely to transact successfully), the number of times their agents are reaching out to prospects, and who the most productive agents are.

So our product needs to include features such as reporting on listing trends, providing insights into communication trends between agents and prospects, and ranking agent profitability.

And, we need to do all of this without sacrificing the agent’s usr experience.

Although our Choosers (brokers) are paying for the product, they’ll derive no value from it unless our Users (agents) find enough value in it for themselves to continue to using it. For example, brokers will find a lot of value in understanding the number of times that an agent reaches out to a prospect, and how that number correlates to the the likelihood of closing a listing. But, an agent won’t log those interactions into the system without getting some value out of that action themselves. This means that in addition to the broker facing feature of correlating interactions to listings, we also need to design an additional agent facing feature that incentivizes them to log their interactions in the first place, such as letting an agent know when it’s been more than two weeks since they reached out to a prospect. Otherwise, agents won’t log their interactions and brokers won’t have anything to report on. And if our Users don’t find enough value to keep using our product, then our Choosers won’t find enough value to continue to pay for it.

So What Do We Do About It?

So, what do we do about this? First need to understand who are Choosers and Users are, and whether or not they’re the same person. Next, we need to determine the incentives for each group to use our product. What do our Users hope to get from our product and what do our Choosers hope to get from it? And finally, we need to understand how the incentives for the Users will create value for the Choosers…or if gaps exist where they don’t. For example, what element of value do Choosers wish to derive that Users are not incentivized to provide? Once we understand where these gaps exist then we can design features and flows to help create the value expected by both.

By keeping this in mind, we can ensure that we create not only a product that our Users will love, but also a product that our Choosers will pay for. And then, everyone will be happy.


This post was originally published on the Front Row Agile blog.

Scrum Board with Firelane

Help! My Team Keeps Missing Releases

Lately, I’ve seen a recurring anti-pattern across several different scrum teams.  The pattern works likes this: a team forecasts a certain number of points per sprint and regularly completes that same number.  If you were to plot the team’s hit rate, or number of points completed over those forecasted, then you would see a fairly straight line at 100%.  The plot below represents a team who, after an erratic first few sprints, has settled down to a particular 100% hit rate.

Hit Rate From the outside, it looks like the team is right on track.  But, as they begin to near the end of the release, everyone starts to realize that the picture isn’t quite as rosy as first thought.  In fact, it becomes obvious that they’re not on track at all to complete all planned work in time for the release, even though they had consistently completed the same number of points they had forecasted.  How does this happen?

Finding the Churn

This can occur when the team regularly accepts new work during the sprint that pushes the planned work to the side.  This work, which often takes the form of high priority bugs or customer issues in production that must be fixed immediately, is estimated and added to the sprint alongside the existing work.  Often, this “high priority” work pushes the previously scheduled work to the side.  At the end of the sprint the team celebrates completing the right number of points…unaware that they actually completed the wrong points.

How can we catch this before we near the end of the release so we can do something about it?  By tracking “point churn”.  Churn is the number of points added to a sprint after it has begun.  Typically, we discourage adding work to an in progress sprint but some teams follow this practice to handle high priority work that must be addressed quickly.  These teams can get early insight into their churn by plotting the number of points added to their sprint alongside their hit rate.

Hit Rate with Point ChurnThe plot to the right adds an additional line along side hit rate to indicate point churn.  The red line, bound to the right axis, represents the number of unplanned points added each sprint.  You can see that although the team maintains its 100% hit rate, more and more points have been added each sprint.  This could be an indicator that although the team is completing the right number of points each sprint…they could actually be completing the wrong points.

If you notice that your hit rate is consistently around 100% but your churn is regularly above 0 then this is can be an indicator that you’re falling behind in your overall release, even though you’re completing the planned number of points each sprint.

A Simpler Approach

But there is another approach.  Rather than go to the effort to track unplanned work that is added to each sprint, an alternative approach is for the team to still accept the unplanned work but not award any points to it.  In this model the work is not added to the sprint, but it is still tackled alongside sprint work.  This approach is easier since it doesn’t require tracking additional points and, if the team reaches the end of the sprint and still has planned work outstanding as a result of being distracted by the unplanned work, then the hit rate for the sprint actually provides a more accurate reflection of how the team is likely to pace for the overall release.

To make new work more visible in this approach you can even add an additional lane to your sprint board for it to flow through.  Seeing this work alongside your planned work, especially with team members assigned to it and Work in Progress limits respected, is a wonderfully effective way to illustrate the impact that new additions can have on your sprint plan.

Scrum Board with Firelane

In the image above, we’ve added an empty row to the bottom of the standard scrum board to allow unplanned work to flow across the board.  These cards are red to indicate their importance.  However, note the WIP limits for each state called out in parenthesis at the top.  Deploying has a WIP limit of 1 meaning, that the unplanned work is currently blocking release of the planned work for the sprint.  Adding an explicit lane to the scrum board can more visibly call out the effect that unplanned work has on a team’s productivity rather than the team simply accepting the work but then quietly falling behind.

Whichever approach you choose, asking whether your team is completing the right points instead of just all of the points can provide early insight into your team’s pace and give you the opportunity to correct your course before its too late.

Want to learn more about planning great releases and keeping your team on track? Check out my course Agile Release Planning on Front Row Agile to learn how.

Top Down Release Planning

Release Planning from the Top Down

Quick…what was the killer feature in your last big release?  If your release is like most then you’ll probably have trouble answering that question.  In fact, if your release is like most it was probably filled with a grab bag of low quality features and a handful of bug fixes.  Sure, there may have been one or two important features in there, but for the most part they were buried amongst an avalanche of noise.

Bottom-Up Release Planning

Bottom Up Release PlanningWe call this type of release planning Bottom Up Release Planning.  It often begins with simply combing the backlog for stories that need to be released and grabbing as many as you can fit in your next release.

Sure, there are advantages to this, most notably that it’s easy to do.  Release planning tends to be simpler and take less time using this method.  In fact, you’ve probably seen these types of releases before, they often begin with a “wishlist” of features that absolutely must be in the next release.

But releases planned in this way tend to feel disjointed and often fail to make an impact on your users since there’s nothing tangible for them to bite on to.

Top-Down Release Planning

Top Down Release PlanningThere’s a better way…and we call it Top Down Release Planning.  This type of release planning occurs when we first define an objective or goal for each release and then select only those backlog items that fit that objective.

This type of release planning can be a bit more involved since we must decide if each item selected fits the objective of the release, but it can lead to much more cohesive releases.  These types of releases often make a bigger impact on users which can resonate with them for a long time to come.

Why Bother?

You may be wondering why if Top-Down Release Planning is even a little more difficult then why we put forth the extra effort?  Well, aside from the advantages I mentioned already, highly cohesive releases tend to be much easier to build a memorable marketing message around.

In addition, focusing the release on a key objective also allows us to make greater strides in trying to solve a sticky problem that our users are currently facing.  If we can solve a particular pain point—and build a great message around that solution—then we’re much more likely to deliver a release that will resonate with our users.

Want to Know More?

I cover Top-Down Release Planning in more depth in my course new course Agile Release Planning, available on Front Row Agile.  If you’ve ever struggled with building large-scale projects using agile techniques, or have just wondered how planning works in an agile framework then this course is a great fit.

In addition to Top-Down Release Planning I also cover

  • How traditional planning and agile planning differ, and how to start adopting a more agile mindset.
  • How to develop a vision for your projects, including creating a vision board and learning proven techniques to cultivate focused concepts.
  • Strategies for building a roadmap to your goal and important things to consider in the first release and all future releases.
  • Ways to plan the release, including how to develop a release grid and prioritize features well.
  • How to build the product backlog by looking through the lens of DEEP and constructing effective sprint plans now and far into the future of your agile development.
  • Methods to keep plans on track when things just don’t go as you expect.

This course is regularly $50 but for a limited time readers of this blog can get all of this content for just $40 by using the discount code PLANBETTER at checkout.  That’s an additional 20% off just for following this blog.

Just enter the code above to claim your discount and be on your way to planning great releases and I’ll see you in the course!


Where Afternoon Standups Go Wrong

Most teams are familiar with the morning standup, or the classic scrum ritual that gives teams the opportunity to sync up and plan their work for the day.  For many teams, the morning standup is the bread and butter of their scrum process.

But every once in a awhile a team tries to move their standup to the afternoon.  The reasons always sound legitimate:

“Not everyone gets here at the same time, so we’ll just hold our standup in the afternoon.  That way everyone can attend.”


“Mornings are when we’re most productive…we don’t want to interrupt that with another meeting.  Let’s just have the standup in the afternoon.”

As valid as these reasons sound afternoon standups have a tendency to be less useful than morning standups, but the reasons why aren’t always clear.  Let’s take a look at why.

The Ritual Suffers

The standup ritual suffersMorning standups create a nice ritual for your team.  Everyone trickles by 9 o’clock, checks their email, and gets their morning cup of joe.  But, at 9:30 everyone filters into the team room and it’s time for the standup.  After a quick standup the team starts their day for real.  The 9:30 standup is the signal for the day to start.

On the other hand, even though afternoon standups are still scheduled at the same time every they are much less likely to start at the same time every day.  This is because by the afternoon the day is much more likely to have gone awry.  Maybe tasks have taken longer than expected so not everyone is ready.  Perhaps a fire has much of the team too distracted to make the original time.  Or, even if all of the team is available, maybe other meetings outside of the team have ran long and the team’s normal meeting space isn’t available.  Now the team has to hustle to find a space that can accommodate them for their already late standup.

Standups Last Longer

No one likes a long standup.  In fact, one of the most common complaints from new scrum teams is

“Our standups always last at least 45 minutes.”

All standups are susceptible to this but afternoon standups are particularly so.

Standups last longerThink of how you feel in the morning:  You’re energized for the day, you’ve had a fresh cup of coffee, and you’re ready to tackle that sticky problem from yesterday.

Now, think of how you usually feel in the afternoon:  You’ve just had lunch.  You’ve already been at work for 5 hours, and all you want is a reason to sit down and take a break for a bit.  The afternoon standup is that reason.

And, once everyone has sat down, the standup begins to drag.

Your New Status Meeting

But, the most insidious problem of all with afternoon standups is much more subtle.

Standups should have two goals…

  1. Identify blockers so they can be brought to light and removed.
  2. Allow the team to sync up and plan their work for the day.

Nowhere in that list is a goal for the team to report the status of their current work in progress.  That’s not the purpose of the standup…that’s the purpose of the scrum board.

Morning standups are very conducive to these goals since they encourage the team to identify blockers early in the day and to synchronize the day’s work before they get started on the wrong path.

But afternoon standups share neither of these traits.  Although the same blockers might exist in the afternoon as they did in the morning, team members are less likely to bring them to light since they may mistakenly believe they’re close to solving them.  Even if they do, the other team members are likely too deep into their own tasks to volunteer much help.  In addition, since the individual team members have already started their work for the day there’s no opportunity to synchronize the work as a team…everything has already begun.

With both of these options off of the table only one thing is left to talk about in an afternoon standup…status.  When held in the afternoon the focus of the standup naturally shifts to what each team member has accomplished so far that day.  Rather than providing the opportunity for the team to clear their own way and plan the day’s work ahead, the standup simply devolves into yet another status meeting.

Try It and See

The differences between afternoon and morning standups are subtle but the results can vary dramatically.  If your team is currently using afternoon standups and something just doesn’t feel quite right then give morning standups a try.  The difference may surprise you.

Want to see more about how to make textbook agile work on real teams? Check out my course, Agile in the Real World, for tips and techniques for making agile really work in your organization.

Don’t have a Pluralsight membership yet? Try the entire Pluralsight course catalog free for 10 days here.

Product Backlog

Splitting User Stories Across Teams

I recently received a question by email wondering if large user stories should be split across teams.  The question was so interesting that I thought I would summarize my response here.

Sometimes large user stories are broken down into smaller stories that are tackled by multiple teams.  For example, imagine that your organization has two teams: a team that owns your web application and a team that owns your mobile application.  If you are releasing a feature across both platforms you may originally start with that feature described as a single user story but then split the story in two as each team tackles their respective implementations.

When multiple teams work on a single product we like to keep a single Product Backlog that all teams share. This lets the Product Owner see the big picture at any given time which helps keep them focused on the overall vision for the product.

Even if a larger story that will ultimately be split across several teams we tend to keep it as a single story during the Product Backlog phase.  This helps to prevent us from getting mired in the weeds of each story too early and makes the story easier to move up and down the backlog as new priorities emerge.

Product Backlog

Keeping the story as a single unit also it makes it easier to assign an estimate to.  Admittedly, we know that the estimate won’t be as accurate as if we broke the story down and estimated each individual part, but that’s ok.  We accept that estimates are less reliable during this stage and only use them for getting an idea of the complexity of a story relative to other stories in the backlog.

Splitting User Stories During Sprint Planning

However, during Sprint Planning the top stories in the product backlog are moved into a separate Sprint Backlog for each team. At this point those same large stories are broken down and split into separate stories for each team, who then take this opportunity to estimate their individual portions. The sum of those estimates may add back up to match the original estimate of the large story, but don’t be surprised if they don’t.  Breaking larger stories down into smaller stories often tends to expose gaps that we didn’t originally consider when the story was in its larger form, so new stories may emerge as a result.

Product to Sprint Backlog

Allowing each team to work from their own Sprint Backlog minimizes the number of dependencies each team needs to complete their work.  We want each team to have as many of the skills as possible to complete a valuable increment of the product during each sprint, which is one of the reasons why we strive to make scrum teams cross-functional.  If a team can still deliver a valuable increment themselves, then we want that work split only into the portion that they can complete.

In addition, Velocity is our primary planning metric in scrum.  Teams who estimate in story points eventually start to evolve those points to the range that makes the most sense for each team.  Put another way, a story point for one team may be wildly different than a story point for another team.  This flexibility is what gives story points their power as each team starts to assign the most accurate value to each point that makes sense to them.

The side effect of this, however, is that the Velocity of two different teams can start to vary wildly even if each team is completing roughly the same amount of work.  For this reason we want to be able to map a separately velocity to each team which better represents the amount of work they’re completing during a sprint rather than trying to roll all velocities into a single number.  This gives us a more accurate representation of how much each team tends to complete during each sprint, which lets us plan the overall product even better.

Want to learn even more ways to split your user stories so your team can start working with them immediately? Check out my course, Creating Effective User Stories, for easy techniques that will have you writing better user stories today.

Don’t have a Pluralsight membership yet? Try the entire Pluralsight course catalog free for 10 days here.

User Stories, Themes, and Epics are often represented by sticky notes

Themes versus Epics in 2 Minutes

The difference between themes and epics are a common sticking point for many teams first diving in to user stories. Not only can descriptions of both topics often be vague, but the difference is often muddled further by many project management tools that use the two terms interchangeably. However, the difference doesn’t have to be so hard.

Load More
10 of 22