New answers tagged user-stories
0
While preparing a Developer level Document (Use Case) what should be defined in Business Validation?
"Like for example, we are writing a use case for creating a user, what should be involved in Busines Validation?"
Best approach is the clearly define which actors are involved, the depender and dependee. then show the actual role of each to the dependum(Current use case).
Use Case are meant to be simple, if we talking creating,
who has rights to ...
0
While preparing a Developer level Document (Use Case) what should be defined in Business Validation?
As per Wikipedia, Business Process Validation (BPV) is the act of verifying that a set of end-to-end business processes function as intended.
In other words, this is not checking that the app doesn't crash, rather, it's checking the app does what you designed it to do.
So, in your example of writing a use case for creating a user, the Business Validation ...
0
While preparing a Developer level Document (Use Case) what should be defined in Business Validation?
Ask the customer, user or business team what validation they would expect. Keep the documentation as brief and simple as possible. Encouraging the users to see and try out the software, talk to the development team and give their feedback is much more important than what you write down in any document.
0
As Bogdan already mentioned: "the team owns all of the stories", & the team should also owns the way to get those stories done. I mean pre-assigning to individual member or pulling when sprint progress are both fine.
One practice in my team is we always have individual owner at story level even when multiple members involve. The owner will be ...
3
The classical User Story format is a way to express three different elements: the who, the what, and the why.
So to improve the your user story, you need to think about why a customer would care to see stores on the map. The purpose is obviously not just to see them on the map, the purpose is to do something with that information: go shopping, waste time ...
3
I'm not sure that the user's end goal is to see the store on a map; I would imagine that what the user actually wants is to visit the store ,or plan a route to the store, or select the closest store.
Just because I feel guilty about an answer without links, let me offer value engineering; that is my go to for understanding the theory behind the achievement ...
1
Since you're asking about user stories, not tasks: A user story usually consists of several tasks that can be tackled by different team members, sometimes even different crafts. That means that, while you can certainly assign team members to any of the story's tasks (though you don't have to do that, either), the story is more likely to be owned by the team ...
2
A "story" does not necessarily correspond 1:1 with a development task. You need to determine from the story what needs to be done, and by whom, in order to complete it.
1
In a situation like this one, I perceive the value of these "stories" to be to capture an understanding of who the actual users of the system perceive themselves to be, what the system does for each of them, and exactly how they do it.
Don't assume that developers actually know this, particularly since they probably aren't the ones who built it.
...
2
Although Product Backlog Refinement is the method by which the team ensures that the Product Backlog Item can be completed within one Sprint and has all of the necessary attributes (description, order, estimate, value). However, since Scrum doesn't mandate the use of any particular tool, it doesn't tell you how to go about using any tool.
Jira gives you a ...
1
Consider having a meeting, called Backlog Refinement, that you run before Sprint Planning. Both a developer and the Product Owner must attend.
During the Refinement meeting, you go over the Stories and do a sanity test, ensuring they fit the INVEST method.
If you don't want to have a Refinement meeting, this can be done during Sprint Planning as well. ...
1
First of all talk to the Product Owner and get their input. One of the good reasons you might want to write user stories for an existing design is to make sure you capture the "so that..." for each feature. It's likely that the team may be asked for changes to the design based on future feedback so if the motivation for design decisions is clear ...
2
First, it is important to consider that, as you already have an up-front design and are simply implementing it, you are not practicing anything like Scrum or XP. This is not a value judgement - it's fine - just realize that the tool of user stories is not designed for what you're doing.
This, in turn, begs the question: Why do you want to use User Stories. ...
2
The November 2017 Scrum Guide defines the Sprint Backlog as:
the set of Product Backlog items selected for the Sprint, plus a plan for delivering the product Increment and realizing the Sprint Goal.
In this definition, the unit of work is not defined. That is, the Product Backlog Item may not be the unit of work that is Done by one or more members of the ...
2
It's up to the team to create the sprint backlog based on the backlog items chosen by the Product Owner. Some teams do use sprint planning to allocate at least some items to individual developers, other teams adopt a "pull system", meaning items are not pre-allocated and it's up to each individual to pick up items off the backlog when they have the ...
3
When the team plans a sprint, they pull product backlog items or user stories from the top of the backlog and into their sprint. The stories they selected to do that sprint now form the "sprint backlog".
Now, concerning assignment of these stories... it depends.
As part of the planning, developers also can decide who does what. Jake could assign ...
Top 50 recent answers are included
