What to do with ill-defined stories?

Question

So, I am the Scrum master for my team, and my team's manager insists on putting stories in the sprint that are ill-defined.

For example, while they have a end goal in mind, it is a poorly defined story... we are not even sure of the systems involved or the level of effort required. Mostly what the story contains is people to talk to to gather requirements.

Now, normally I'd relegate this story to the backlog and schedule some elaboration meetings, by my boss insists this story must be started this sprint.

When I tell him we can't commit to finishing something if we don't know what it is, he responds he doesn't care, it's got to be started this week. The story isn't even for our project, it's someone else's systems and requirements.

He also makes it quite clear that we are judged based on stories that aren't finished by the end of the sprint.

How in the world can I deliver effectively on this? I can't have my programmer do the business analysis work and create a story for next sprint... two weeks is too long.

Do I just say "no", remove the story from the sprint and let him fume, or break process on a fairly routine basis?

Is this indicative of a mindset/culture where Scrum just isn't going to work, and I should stop trying to do the square peg/round hole dance? How can I effectively push back?

Answer 1

TL;DR

You aren't doing Scrum. You're possibly doing something Scrum-like, but your boss needs to read The Scrum Guide, and the Scrum Master needs to take an active role in educating this manager about his role (if any) on the project.

Analysis

Who Manages the Product Backlog

[M]y team's manager insists on putting stories in the sprint that are ill-defined. Mostly what the story contains is people to talk to to gather requirements....[and] my boss insists this story must be started this sprint.

Only the Product Owner may manage the prioritization of stories on the Sprint Backlog. If your "boss" (who is presumably line management) is also acting as the Product Owner, this is a conflict of interest. If he's not the Product Owner, then he's overstepping his role as a stakeholder within the Scrum framework.

Furthermore, while the Development Team must work on user stories from the Product Backlog in ordinal sequence, it is solely up to the Development Team to estimate stories and identify how many of those top stories will fit within each Sprint. In other words, you accept the amount of work you are confident that you can finish each iteration; the volume of work can never be assigned from outside the Development Team.

Requirements Gathering as Stories

It is never acceptable to have a significant scope or requirements change within a given Sprint unless the Product Owner calls for an Early Termination and a return to Sprint Planning. Having your organization violate this basic principle is a serious process problem for the team and potentially breaks the framework.

In addition, one of the biggest causes of framework failure is the inability to deliver a refined Product Backlog to Sprint Planning. The Product Owner (not line management, stakeholders, or anyone else) is responsible for delivering actionable stories to the Sprint Planning Meeting.

While it's okay for the Product Owner to work with the Scrum Master and Development Team during Backlog Refinement to clarify or decompose stories, "requirements gathering" can't pragmatically be a baked-in part of a user story; at the very best, one might add additional user stories about requirements gathering.

A good cross-functional team might have a business analyst. Even if not, as story that says something like:

As a Development Team member,
I need to discuss feature XYZ with marketing
to help define the scope of work for the feature for the following Sprint.

Whether you call this a story spike or simply requirements gathering, this is an acceptable story because it clearly makes the cost to the project visible (e.g. that requirements gathering isn't free), and allows the refined story to be fed onto the Product Backlog during Backlog Refinement to be prioritized by the Product Owner, and eventually estimated and accepted by the Development Team during some future Sprint once the story reaches the top of the Product Backlog.

Scrum Master as Educator and Referee

The Scrum Master is the process referee. When you see "framework fouls" like this, you need to pull out the red card and blow your metaphorical whistle. Furthermore, you need to provide adequate education about the framework, its defined meetings and artifacts, and the roles and responsibilities within the Scrum framework and the organization to everyone in the organization. Whether or not your boss is properly a member of the team is something I can't assess (although I suspect not), but your role as Scrum Master is to work with him to define framework-appropriate ways for him to interact with the team within the scope of the framework.

If you are unable to do that, or if he is unwilling to adapt to the requirements of the framework, then you may want to start dusting off your resume. It doesn't matter whether the problem is an inexperienced Scrum Master or a command-and-control line manager; both are key ingredients that are statistically likely to lead to project failure, and unless your job title is "Professional Scapegoat" I wouldn't stay in a situation that is likely to lead to a career train-wreck.

As always, your mileage may vary.

Answer 2

CodeGnome has a good summation of the root cause. Your boss doesn't understand or is not bought into how Agile works. That's a pretty big problem. That falls into agile adoption issues, which is a bigger question that you asked.

The short term fix, for this sprint, is acceptance test. Take a few minutes with your boss and find out what would be his measure of if the feature is done. Apply the 5 Why questioning technique and drill down. It can be done pretty quickly, so as to not "waste" his time. With a solid understanding of what he considers a success, your developers should be able to figure out what to build.

Best-

Answer 3

Your boss has probably identified the technical uncertainty you're facing. For him, it's a risk. That's why he wants the story started now; so that this risk can be fleshed out.

Instead of committing to getting something done, embrace the uncertainty and commit to having something on which you can get feedback. Break this into a spike, with the rest of the story to follow afterwards.

Rigid adherence to Agile / Scrum principles in these situations has a tendency to push high-risk (and usually high-value) items further down the backlog. Even trying to get clear acceptance criteria on something the business have never tried before can be tricky. By all means have the conversation with your boss, but let him know that it will be more than two weeks until you're finished, and that you'll keep him updated with progress.

If, after this, your boss still insists on holding you to rigid estimates in the face of uncertainty then he's an idiot, and it's time to find a new job.

If you want to know more about spiking vs. analysis and when to do each, look up Cynefin or some of the recent articles I've written on BDD and uncertainty.

Answer 4

It's simple.

Be harsh and delete the entire story and make the person who wrote it to re-write it properly + report to the boss, CTO and the CEO. It is the only thing which works.

Wise men build and destroy.

Answer 5

I think there is a deeper problem, if your boss tells you to do something he's not able to properly define. But from the few information you gave, I cannot judge what it might or might not be.

That being said, I'll try to tackle your current problem:

If you cannot decide whether the story is an epic or not, treat is as an epic. First, separate stories for the things the devs know how to solve. Pull these. Then separate stories for further investigation on the things they are not sure about. Estimate how much effort you want to spent in searching for solutions. Pull these stories too, if they fit. What remains is a ill-defined story with an ominous "rest". You cannot pull that.

As devs work on the sprint, they either find solutions to the problem-stories -- then the "rest" disappears -- or they get, at least, a better understanding of the problem. If the problem wasn't solved, they can then better estimate the remaining effort for the next sprint.

The crucial point now probably is, how much to invest in the research stories. This depends on the stories importance to your boss/the client (btw. who of them is the PO? There should only be one...). Estimate more effort, if you're unsure and the part is crucial. Less, if it's optional.

Hope this helps!

Answer 6

Have you heard of 5 Whys? See if you can get some context for the stor[y|ies] they want to add.

Is it because your team is much more consistent at delivering value? Show that adding work leads to multitasking that will slow you down.

Is it because of a date dependency? Make that information transparent and negotiate|prioritize based on cost of delay

Is it because your boss just doesn't know how to write stories? Work with them to get better at it and understand there are acceptance criteria for work to be started much like there are for work to be completed.

Is it because they believe in extrinsic pressure over intrinsic motivation? Show numerous studies that this is detrimental to performance.

Change the organization, or change the organization.

Answer 7

In my opinion if the boss is requiring this feature this strongly it is because it's something he really needs for the business, and ultimately that's what pays everyone's salary.

SCRUM is a great set of tools that helps being more productive, but sometimes its strict rules don't apply very well to the real world.

Of course the boss needs to understand better how scrum works and try to adapt to it. It's like your boss is trying to drive a car but refuses to use the steering wheel, the car might get somewhere, but hardly where he means to.

These considerations though should have been tackled earlier, now you are facing a situation that looks like an emergency. If your boat is sinking it might not be sufficient to plan closing the hole during the next sprint, even though closing holes in the hull might not have been agreed in the sprint planning. Staying afloat gets priority on any procedure.

I would advise to comply with the request on a 'best effort' basis, try to push back the proper specking of the story so that you at least can work on it knowing what's required from you. Basically try to adopt scrum as much as you can, but remembering that this is an emergency situation.

I would also note everything down and at the next sprint review discuss it with the team, try to get proposals on how to tackle future similar situations, and then you might need to have a chat with the boss, to explain him the consequences of his request, and you will be in a position to discuss effective proposals (from the team) and because they won't be coming from you alone, but from the entire team, the boss will not be able to discard thing easily.

You, the team and the boss are on the same boat, everyone's actions have consequences, you all have the same goal, but different visibility.