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

☆樱花仙子☆ 提交于 2019-11-30 02:31:04

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:

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.

  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.

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

易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!