New answers tagged user-stories
7
I'm not convinced that what you describe fits the notion of "large, non-reducible tasks". So far, I'm also not convinced that any piece of work is large or can't be reduced to something that can be done within a Sprint.
Fixing a critical bug that is hard to pin down and resolve
The steps here are pretty straightforward: Get reproduction steps. ...
-1
In my experience, "there is actually more than one kind of 'story.'" In any software system, the functionality is always interlinked and therefore interdependent. Some of the "stories that need to be told" have to do with these internal interdependencies, which may never be directly or even indirectly apparent to any "user," ...
1
Another observation: *"as you proceed along this process of refinement, the 'stories' will quite-naturally cease to be 'user' stories." You are now deep-diving into the world of "how the existing software now works," and into "how now to change it, without utterly breaking it." This evolution of project focus is both normal ...
1
Adding to what Todd mentioned, I think that having a user storie that would be split into smaller ones is just confusing. Think about it from a QA perspective: they can't close the big story unless the close the smaller stories.
A better way of looking at it is to have an epic for that "big user story", and then file the stories and engineering ...
2
This is a normal by-product of refinement. Part of refinement is decomposing a specified need into something that can be delivered in a reasonable amount of time. For example, if you're using the Scrum framework, each item in the Product Backlog is something that should be deliverable in no more than one Sprint. Other frameworks have similar expectations for ...
1
Yes, it makes sense. It's somehow inevitable since things start of with a big idea that is then decomposed in smaller and smaller actionable items.
I think you are talking about epics (see more details here: Epics, stories, themes, and initiatives). The idea is that your user stories have a small or large granularity and everything in between. People usually ...
0
When working "Agile" and "Lean" we should eliminate waste, e.g. reduce administration.
So do I create a new feature for this one user story? How would you guys manage this small amount of incremental work in your backlog?
If there is no reason to add more administration, you should not. This sounds like a "git commit" and a &...
0
Just a thought if anyone wants to build it...
Median hours * inverse scale probability range multiplier N hr with d/d average deviation (not standard). On entering N and d a range calculator will write it in english for confirmation.
Where the d is the distribution range half the time because half is simplest.
e.g. 1hr *3/3 (3 hours to 20 minutes, normally 1 ...
0
I think it's fine to repeat some of the acceptance criteria for both stories. The team may decide to complete the two stories in separate sprints in which case the repetition would make perfect sense. If they are done in the same sprint then presumably the people doing the work will understand that the two things have a lot in common.
The team should decide ...
0
Use Tags or Labels for Functional Areas
Your team is misusing the term "feature." What you should be doing is treating the various aspects of your application domain (e.g. authentication) as components, functional areas, or concerns. This allows you to tag or label features, epics, stories, or tasks appropriately within an agile context.
By ...
0
I would suggest your Definition of Done should apply to the story, not the feature. If your feature is Authentication then presumably that can never be completely done because there could always be a future defect or enhancement raised under the heading of authentication. Assign stories to features if you like but don't treat features as done.
Top 50 recent answers are included
