Splitting Epics worksheet

2
Ideas for splitting Epics into User Stories Remember you are looking to develop slices of the business opportunity that produces valuable working software with the potential to generate feedback from users. Sometimes the story slices are not deliverable to end- users but they generate value from the learning gained in producing them. They should all result in testable and demonstrable software. Consider applying the XP principle DTSTTCPW (“Do The Simplest Thing That Could Possibly Work”) Consider the following approaches: What are the visual elements that must be there or can be deferred ? You can make a story per viewing steps on a user journey. You can make a story per enabled elements of an input screen. You can make a simple (not pretty) UI. You can make a command line interface. What scenarios are in scope for acceptance criteria? You can work with a subset of the user scenarios. You can defer conditional steps to other stories. You can defer data validation. You can defer error handling. What architecture decisions or constraints that can be deferred? You can defer optimisation of performance. You can defer internationalisation You can defer working on different platforms / devices You can defer handling large volumes of data. You can hard-code data rather than getting from the real source. You can stub out components. This is not an exhaustive list! Be creative in your story splitting approach.

description

Worksheet about splitting stories

Transcript of Splitting Epics worksheet

Ideas for splitting Epics into User Stories Remember you are looking to develop slices of the business opportunity that produces valuable working software with the potential to generate feedback from users. Sometimes the story slices are not deliverable to end-users but they generate value from the learning gained in producing them. They should all result in testable and demonstrable software. Consider applying the XP principle DTSTTCPW (“Do The Simplest Thing That Could Possibly Work”) Consider the following approaches: What are the visual elements that must be there or can be deferred ?

• You can make a story per viewing steps on a user journey. • You can make a story per enabled elements of an input screen. • You can make a simple (not pretty) UI. • You can make a command line interface.

What scenarios are in scope for acceptance criteria? • You can work with a subset of the user scenarios. • You can defer conditional steps to other stories. • You can defer data validation. • You can defer error handling.

What architecture decisions or constraints that can be deferred?

• You can defer optimisation of performance. • You can defer internationalisation • You can defer working on different platforms / devices • You can defer handling large volumes of data. • You can hard-code data rather than getting from the real

source. • You can stub out components. This is not an exhaustive list! Be creative in your story splitting approach.

Practical Exercise

Concept: Crowdsource your wedding photos Invite guests to contribute and view collected photos from event

Benefits: personal photos – longer timeline including build up to big day – cheaper Costs: web hosting, storage, charging model 5p per upload, 10p per published photo Challenges: privacy, participation, selecting Personas: Kim anxious bride, Geoff non-techie guest, Alex always-on-social media mate.

***** Here are some headline “Epic” stories: ! Happy couple: Invite guests to contribute photos ! Guests: Upload photos ! Happy couple: Select photo set to share ! Guests: Add information about photos ! Guests: View photos

Instructions

! Get into groups of 2-3 people

! Grab some index cards

! Consider one epic story

! Write smaller stories, one per card

! Objective: as many small story cards as you can

! Share one small story with the group at the end