New answers tagged requirements
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 ...
1
You don't need the design documents on Confluence to live in the Jira report. The electronic traceability through the Jira and Confluence UI should be sufficient if you even need that.
Although the traceability reports may be helpful as an export, the most important traceability is between the Jira ticket (often a Story or Bug, or something similar), the ...
Top 50 recent answers are included
