Agile requirements through user stories and scenarios

Transcription

1 Institutt for datateknikk og informasjonsvitenskap Inah Omoronyia Agile requirements through user stories and scenarios TDT 4242 TDT 4242

2 Agenda Key principles of agile requirements User stories INVEST Prioritizing stories User story mapping Challenges Conclusion TDT 4242

3 Key Principles for Agile Requirements Ac#ve user involvement is impera#ve Agile teams must be empowered to make decisions Requirements emerge and evolve as so9ware is developed Agile requirements are barely sufficient Requirements are developed in small, bite sized pieces Enough s enough apply the 80/20 rule Coopera#on, collabora#on and communica#on between all team members is essen#al

4 Requirements are a Communica8on Problem Wri;en requirements can be well thought through, reviewed and edited provide a permanent record are more easily shared with groups of people #me consuming to produce may be less relevant or superseded over #me can be easily misinterpreted Verbal requirements instantaneous feedback and clarifica#on informa#on packed exchange easier to clarify and gain common understanding more easily adapted to any new informa#on known at the #me can spark ideas about problems and opportuni#es

5 User Stories seek to combine the strengths of written and verbal communication, where possible supported by a picture. * Kent Beck coined the term user stories in Extreme Programming Explained 1 st Edition, 1999

6 What is a User Story? A concise, wrimen descrip#on of a piece of func#onality that will be valuable to a user (or owner) of the so9ware. Stories are: User s needs Product descrip#on Planning item Token for a conversa#on Mechanism for deferring conversa#on

7 User Story Cards have 3 parts 1. Card A wrimen descrip#on of the user story for planning purposes and as a reminder 2. Conversa8on A sec#on for capturing further informa#on about the user story and details of any conversa#ons 3. Confirma8on A sec#on to convey what tests will be carried out to confirm the user story is complete and working as expected

8 User Story Descrip8on As a [user role] I want to [goal] so I can [reason] - As a [type of user] I want to [perform some task] so that I can [reach some goal] For example: As a registered user I want to log in so I can access subscriber only content

9 User Story Descrip8on Who (user role) What (goal) Why (reason) gives clarity as to why a feature is useful can influence how a feature should func#on can give you ideas for other useful features that support the user's goals

10 User Story Descrip8on Steps: Start with a #tle. Add a concise descrip#on o9en using this useful templates. Add other relevant notes, specifica#ons, or sketches Before building so9ware write acceptance criteria (how do we know when we re done?)

11 User Story Example: Front of Card

12 User Story Example: Back of Card

13 How detailed should a User Story be? Detailed enough for the team to start work from, and further details to be established and clarified at the #me of development.

14 INVEST in Good User Stories Independent User Stories should be as independent as possible. Nego#able User Stories are not a contract. They are not detailed specifica#ons. They are reminders of features for the team to discuss and collaborate to clarify the details near the #me of development. Valuable User Stories should be valuable to the user (or owner) of the solu#on. They should be wrimen in user language. They should be features, not tasks. Es#matable User Stories need to be possible to es#mate. They need to provide enough informa#on to es#mate, without being too detailed. Small User Stories should be small. Not too small. But not too big. Testable User Stories need to be worded in a way that is testable, i.e. not too subjec#ve and to provide clear details of how the User Story will be tested.

15 Priori8zing stories into a backlog Agile customers or product owner priori#ze stories into a backlog A collec#on of stories for a so9ware product is referred to as the product backlog The backlog is priori#zed such that the most valuable items are highest 15

16 User Story Mapping User Story Mapping is an an approach to Organizing and Priori#zing user stories Unlike typical user story backlogs, Story Maps: make visible the workflow or value chain show the rela#onships of larger stories to their child stories help confirm the completeness of your backlog provide a useful context for priori#za#on Plan releases in complete and valuable slices of func#onality. 16

17 User Story Mapping Spa#al arrangement: By arranging ac#vity and task centric story cards spa#ally, we can tell bigger stories Arrange ac#vi#es le9 to right in the order you d explain them to someone when asked the ques#on: What do people do with this system? time 17

18 User Story Mapping Overlap user tasks ver#cally if a user may do one of several tasks at approximately the same #me If in telling the story I say the systems user typically does this or this or this, and then does that, or s signal a stacking ver#cally, and then s signal stepping horizontally. time 18

19 User Story Mapping The map shows decomposi#on and typical flow across the en#re system. time Below each ac#vity, or large story are the child stories that make it up Reading the ac#vi#es across the top of the system helps us understand end to end use of the system. 19

20 User Story Mapping priori8zing Priori#zing based on product goal Product goals describe what outcome or benefit received by the organiza#on a9er the product is in use Use product goals to iden#fy candidate incremental releases, where each release delivers benefit 20

21 User Story Mapping priori8zing Create horizontal swim lanes to group features into releases Arrange features ver#cally by necessity from the user s perspec#ve Split tasks into parts that can be deferred #ll later releases Use the product goals from your handouts to iden#fy slices that incrementally realize product goals necessary less optional more optional 21 optionality

22 Agile Challenges Ac#ve user involvement can be very demanding on the user representa#ve's #me and require a big commitment for the dura#on of the project. Itera#ons can be a substan#al overhead if the deployment cost are large Agile requirements are barely sufficient: This can mean less informa8on available to new starters in the team about features and how they should work. Usually not suitable for projects with high developer turnover with long term maintenance contract Arguably not suitable for safety cri#cal systems. 22

23 User Stories Summary User Stories combine wrimen and verbal communica#ons, supported with a picture where possible. User Stories should describe features that are of value to the user, wrimen in a user s language. User Stories detail just enough informa#on and no more. Details are deferred and captured through collabora#on just in #me for development. Test cases should be wrimen before development, when the User Story is wrimen. User Stories should be Independent, Nego#able, Valuable, Es#matable, Small and Testable.