Hot answers tagged

10

There are two schools of thought about what an Epic is. Some define an Epic as a large user story, often one that cannot be delivered in a single iteration. However, it can be placed and ordered in a Product Backlog and then be refined by the team when it comes up. The refinement activity will decompose the Epic into a number of User Stories, each of which ...


4

I just wanted to add a little to Thomas's excellent answer. Epics are a solution to a problem. The problem is typically: "Our backlog is a bit cluttered and some stories are quite big". You don't have to use epics, many teams get by without them. Experiment with how you use epics, but always within the context of the problem you are trying to solve. Are ...


2

Let me go ahead and bump-up my reply to "another answer." In a "gym application" as described there are at least two entirely separate groups of stakeholders: customers, and trainers. If you looked at a "story" told by either one of them, you would see only the story-teller. You would largely miss why a particular story was needed, because "the trainer"...


1

The answer to the question of when to storyboard is as late as possible, but not too late. When following an agile approach we aim to be good at responding to change. As such, we try not to put too much detail on our backlog too early. Instead, we look to continuously refine work as we go along, having it ready just in time. This is why the Scrum framework ...


1

If the expected outcome of the storyboarding session is not only a common understanding of the theme/epic, but also a set of stories, and if you want to be able to work on those stories starting from Sprint 1 next quarter because that theme/epic is the most important thing for the business to work on, then you should definitely have the storyboarding session ...


Only top voted, non community-wiki answers of a minimum length are eligible