How realistic it is to write a User Story with "all" the edge cases and scenarios defined? [closed]

Question

Closed. This question is opinion-based. It is not currently accepting answers.

---

Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.

Closed 4 years ago.

Improve this question

Is it really possible in reality to write a User Story with all the edge cases, scenarios, all actions in a 2 week sprint? What if there are small changes that needs to be addressed on a specific scenario which could potentially make the story to carry-over for that sprint?

Often there is a conflicting situation in our team where Design, PO, BA, Dev, QA, PM blame each other.

PO, Design, BA say that these are very small details that will become a lengthy document in itself, hard to say every single nitpick, and QA/DEV should think of these cases when planning. But QA/DEV fight back stating that its not their job, and if its not stated they aren't responsible, they will do only what is stated explicitly.

PM blames, and puts pressure on BA, Dev, QA that he is only bothered about velocity, with out really helping anyone. Points, points, points that's all he talks about. He does not even help team to focus on product, manage conflict, provide/facilitate training or process that can improve. He does not even understand if a build fails, environment is down the QA and Dev work will be delayed.

What should a developer/qa focus on? Is it getting the story points or getting the product out with quality?

Who should really be bothered about the points? Can PM put pressure on Dev, QA, BA without really understanding the reality?

Who is really responsible for missing out the finer details? Design, PO, BA? Or should QA/Dev should have thought about it before estimating?

The situation is aggravating day-by-day, lot of politics and schism in our whole relationship!

Probably a follow-up to this questions: In agile/scrum user stories, how much detail is enough?

Answer 1

Well, Many guys "forgot" the main purpose of "User Stories". User stories are so small that can be written on an index card. So many user stories are not really "cooked requirements" which developer can implement.And that is the "main point" of user stories: So developer should ask question and keep touch with customers-product owner while implementing it.

User stories SHOULD cause teams and customers to talk more.

But this may not be realistic for your situations.You may not have onside customer or have difficulties to contact regularly.You may be in a situation in which "contract or outsourced development" in which you should do conversation based on documents.I know this is not good situation but after all we are just developers and sometimes we can not able to change working environments and styles.[of course leaving the project is always an option :-)].

But still in that situation, it is not realistic to get all requirements details before project started. You should still use evolutionary requirements with iterative development. *And instead of User Stories you can use Use Cases to slice your requirements so that you can "bite" it at one iteration*. So How to Work With Use Cases in Iterative Methods?

For this Check Craig Larman's Free Book Chapter : He explain it at part 6.21 [ based on RUP]. applying-evolutionary-use-cases. And Ivar Jacopson introduce newly "use case slices". Check Free Use-Case 2.0 ebook

And Some Concrete Answers For your Questions:

-Is it getting the story points or getting the product out with quality?

I think you also new the answer: getting the product out with quality is our focus.

Who is really responsible for missing out the finer details?

It seems that your company involved in Agile Hype but they really does not understand it.If you have "silos" like separate QA, BA, or Design Team , you will continue to play "blaming game".

You are all responsible for failure. And it is OKEY to fail. Software development is experimental activity. The important thing is fail FAST,EARLY and CHEAPLY. One way to make all of you responsible is creating Feature Teams instead of Silos.http://featureteamprimer.org/

To get more understanding the basics of Agile and this "blaming game" roots, watch Larman's video on YouTube Scaling Agile & Scrum with Offshore Development .PS: Although the talk is about Offshore Development and about Scrum, it is gives really deep insights about basics of Agile.I think it will make you also "smile". :-)

Answer 2

It may be possible, but I would not recommend writing a user story with all the edge cases and scenarios defined. Consider what (if any) the difference is between a "user story" and a "scenario". It seems that you have a complex story that would benefit from being decomposed into several stories, perhaps one for each of those scenarios. Your concern over the story "carrying over" from the sprint also indicates a need to break the story down.

Of course there is a point of diminishing returns, but it seems that you're on the too-large end of the story definition spectrum here. For those edge cases that are truly fine-grained enough to belong under a single story, capture them as acceptance criteria.

The other red flag in your post (there are many questions there) is the treatment of story points as a means to keep score of value delivered. Story points should be used as an estimation tool only. The typical (fibonacci) scale is intentionally imprecise and being estimations they should be considered inaccurate. Additionally, the scale is subjective and so will vary from scrum team to team. No one should be bothered about the points except the team estimating their stories. Their concern should go no further than whether it's an effective tool for sizing stories and thereby allowing them to effectively determine how much they will accept into a sprint.

It's very important the entire organization understand that story points are not for keeping score, and are exclusively an estimation tool. Communicate this broadly and clearly. Also, it may be worthwhile to keep that estimation data internal to the team's planning to help interrupt this anti-pattern in your org.

Answer 3

If the domain is totally familiar to you (the team), everybody has understood the requirements perfectly and all the stories are independent(not interlinked) then yes, it is realistically possible.

This is usually possible right at the beginning of a project or in simple projects or in trainings!