I am from an XP background. I know the process very well and have solid working experience with it. I have found it to be the best way to develop software.
I find myself in the position of a process doctor of sorts and this creates much self examination and revaluation of my own understandings.
A very common thing I hear is that some work can’t be made into stories. I personally don’t believe this. The excuses include
- Its too big (The developer will have nothing to show until the end of 5 weeks).
- it’s a complicated algorithm or abstract concept (will take 5 weeks to write and nothing to show).
This question is to get hints, tips or suggestions.
I am looking for hints, tips, and suggestions as to how to address these and similar perceived problems (and more if you can think of them).
I will mark the answer that has the most information on how to get around users/developers who wont write stories and address their many excuses as to why not (I have only listed a few and there are many more).
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...
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).
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.
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.
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.
- 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.
- 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.
- 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.
Its basically the duty and responsibility of the product owner. And there can be any requirements/task that cannot be split into User Stories. I found many such discussions on SCrum Master Forums
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
来源：https://stackoverflow.com/questions/1714557/user-stories-problems-that-cant-be-made-user-stories