This article looks to discuss Epic Features and User Stories and Personas. This article is part 2 of an 2 section discussion on developing Epics and focusses on the Product Owner role in the development of Epics. Part 1 is available by following this link.
Epic Features and User Stories
A 59 Seconds Agile Training Video
Continue to Part 3 Below
Epic Features and User Stories For Product Owners – Part 2
A 59 Seconds Agile Article
Epic Features and User Stories: Story-Writing Workshops
Another excellent method for collecting details about epics and user stories is to set up a workshop and invite along the users, the Scrum team, and any other relevant stakeholders. During the session, the attendees will brainstorm and provide their feedback on the list of requirements. By gathering everyone in one place like this, the time can be used productively to delve into the different aspects and nuances of the features in question, thereby allowing the Product Owner to elaborate on several user stories within a relatively short space of time.
Epic Features and User Stories: Questionnaires
Questionnaires are useful when there is a large user population and a deeper level of detail is needed on user stories or epics that have already been defined. They should only be used as a means to further refine information that has already been collected, and not as the primary mechanism for gathering requirements.
Epic Features and User Stories: Prototyping
A somewhat different technique that can be used to gather the specifications for a user story is prototyping. This involves creating a sample or model of what the feature will look like when it is complete. When this is produced and shown to the eventual users, what happens is that they are able to visualize the functionality in action in a much clearer way than simply talking about it. As a result, any flaws or misunderstandings are more easily pinpointed and ironed out, and there is a greater likelihood that the user story will be delivered smoothly and will meet expectations.
The Use of Personas
Personas are fictional characters that the Product Owner defines in detail to represent the characteristics and behaviors of different users. The purpose of these personas is to get a thorough understanding of what each user is trying to achieve when using the product that is being developed. These are then used within the user stories to clearly define who the requirement is referring to and what goal they are aiming to accomplish when using the feature being described.
Our Favourite Agile Books
We found these books great for finding out more information on Agile Scrum:
Tracking Epics
Aside from having the initial benefit of allowing the broad capture of the requirement in the early stages, the grouping together of multiple user stories into epics has another advantage that comes into play later on, when the items within the epic begin to be placed into sprints and then completed and delivered. While developers and the Scrum team will mostly be concerned with user stories at the most granular level, the Product Owner as well as managers and other stakeholders will tend to be interested in when the epic will be delivered as a whole, since it is only after this phase is complete that the full business value will be achieved. Because of this, many of the agile management tools that are available have the ability to roll up the progress of the child user stories into the epic, and therefore give visibility and allow interested parties to monitor and measure the evolution of the product.
Prev <— Continue Reading —> Next
Epic Scrum Requirements
A 59 Seconds Agile Video Animation
Prev <— Continue Reading —> Next
User Stories Applied
A 59 Seconds Agile Book Review
User Stories Applied by Mike Cohn is one of our favourite books on Agile User Stories. The book starts with an overview into user stories, and details what a user story is and the different aspects of them. He then discusses how to go about writing a user story, and provides details of the INVEST criteria that can be used to determine if the story is meeting all of its objectives. Next Mike gives an in depth discussion of who user stories are written for and where to begin when gathering the details for them. The book then discusses acceptance testing user stories, including how to go about specifying these criteria and the responsibilities of the development team and customers during this process.
Prev <— Continue Reading —> Next
Developing Agile Epics
A 59 Seconds Agile Infographic