User Stories - Problems that can't be made user stories [closed]

Answer 1

Usually when you get "it's too big", what they are really saying is "I only have a vague idea how this should work". You need to work with them to better define it until it becomes possible to split it into logical parts that can be more easily managed.

Answer 2

So basically, your question is "What can I do if people claim a task is too big for a user story, and can't be split up.

In my experience, almost any problem can be split up. Ask them if they can implement a simplified version, leave out advanced features, maybe even use default values in some places; basically anything to produce something that gives meaningful (i.e. testable) results within one iteration.

Remember: The point of an iteration is not to deliver complete functionality, but just useful and testable functionality.

This splitting can be difficult, but it forces you to consider what you really need first, which is very valuable. The developers may bitch about it (I often do myself :-)), but it's really necessary. Breaking down big tasks into manageable user stories is at the very heart of all agile methods.

That said, if the task really, really, really cannot be broken down (think complex mathematical algorithm in a research setting, that takes weeks to even understand the basics of), then your iteration is too short. The iteration needs to be long enough to produce meaningful results. And if most of your problems are so hard that they take 2-3 months to get anything done, then that's your iteration length. But I've never seen a project where that was really the case...

Answer 3

users/developers who wont write stories

Users aren't supposed to write user stories. They aren't supposed to tell you user stories. You can expect them to talk about how they work, the problems that bother them and what they would like to have to facilitate their everyday work.

You, in your turn, is supposed to listen to them and take notes. If they allow, use a tape recorder or a camera. Then you bring the collected information back when you replay it and identify what you call user stories. You discuss them with the team and when you have agreement you have use cases to target in your development.

What role developers play, is up to you. If they just coders, they don't take part in the process. If they in part act as consultants, then they help define user stories.

Answer 4

Here are a few resources that I've collected over time and that might help:

• Patterns for Splitting User Stories
• Story Weight Reduction Toolkit
• Twenty Ways to Split Stories
• Ways to split user stories

Too big or too complicated, there is always a way to put a story on diet (maybe you won't obtain the final result in one iteration but this doesn't mean you can't and, well, there will be more than one iteration).

Answer 5

If development team claims that the story is too big and can not fit within the sprint.. take their feedback and try to split the story with must have and nice to have tasks and try to split it based on that.

check this flowchart.. can be a help: http://www.agileforall.com/wp-content/uploads/2012/01/Story-Splitting-Flowchart.pdf

Answer 6

The "algorithmic specification" problem is common.

Many people prefer to write code and don't really care who the user is or what they do.

I try to get them to focus by asking these questions.

1. What action can the person take? What could they possibly do with the information? If they have some responsibility, they can take action to deny, approve, hold, reject, reprocess, stop, start, something. If the user can't take any action, you need to ask if they're really stake-holders.
2. What decision do they have to make? How do the decide which action (if any) to take? We can't automate that decision -- that's why people are in the loop.
3. What information does this person need to make the decision to take action.

Information-Decision-Action.

We only write software to prepare information for people to make decisions so they can take action.

If that's not the focus, then the stories get out of control.