User Stories. Wednesday, January 23, 13

Transcription

1 User Stories 1

2 User Stories and their friends: Use Cases, Scenarios, Personas, Gherkins and Kanbans 7 W s Who writes user stories? What is a user story? When is it written? Where are they seen? Why is it written? How are they written? How are they used? Whenever you want to explain something, it is often useful to consider the W s. 2 Who, what, when, where, why start with W. How does it work? How much...? The How s end with W.

3 A user story identifies an idea. A user story identifies an idea. 3

4 User Story - What is it? Template: As a <role name>, I need <business capability>, in order to <business benefit statement>. A user story is a reminder to have a deeper conversation with the user (or user rep). It provides a place-holder in the backlog. What is it? Here is the standard template for a user story. 4 The purpose of a user story is to serve as a reminder to have a deeper conversation with the user later. The card or sticky-note provides a place-holder in the backlog.

5 User Story What, When, Where, Why, Who What: Short description of a want/need. When: Someone (?) thinks of a new feature. Who: Why: The business prioritizes requests. Track the request and resulting work. Where: Story cards are seen on Kanban boards. What is it? 5 It is a short description of a user`s want or need. Speaking of that, you need to keep track of where it came from. If it sits in the backlog very long, you may forget who proposed or asked for that feature.

6 User Story What, When, Where, Why, Who Example: - As a product owner, I need to know who is using which features, in order to justify budgets and prioritize maintenance. Who: which role / persona needs What: some product feature Why: expected benefit. Here is an example of a user story. 6 It has its own W`s - What is wanted by whom and why.

7 When someone thinks of a new feature. You can write a user story whenever anyone things of a new feature. 7 But most user stories come from the business - the owners and users of the system. But beware of ideas that don t come from actual end-users. They may sound neat or just serve a single user`s whim. Business managers are notorious. They may ask for a report that they only read once.

8 User Story What, When, Where, Why, Who What: Short description of a want/need. When: Someone (?) thinks of a new feature. Who: Why: The business prioritizes requests. Track the request and resulting work. Where: Story cards are seen on Kanban boards. The best time to record a user story is when it is first suggested. 8 However, that may be in the middle of a busy meeting. The best thing to do is make a note, and then, follow-up as soon as you can.

9 User Story What, When, Where, Why, Who What: Short description of a want/need. When: Someone (?) thinks of a new feature. Who: Why: The business prioritizes requests. Track the request and resulting work. Where: Story cards are seen on Kanban boards. The business is responsible for providing priorities. 9 When there are several business stakeholders with differing priorities, you need a way to sort things out. Use a long table or wall where the business representatives can sequence the stories from low value to high value so that the highest value stories can be worked soonest.

10 Business prioritizes user stories in the backlog. 10

11 User Story What, When, Where, Why, Who What: Short description of a want/need. When: Someone (?) thinks of a new feature. Who: Why: The business prioritizes requests. Track the request and resulting work. Where: Story cards are seen on Kanban boards. User stories provide a way to capture feature requests in a reasonably clear style. 11 Once captured you can use any requirements management system. But, most agile folks prefer Kanban boards.

12 User Story What, When, Where, Why, Who What: Short description of a want/need. When: Someone (?) thinks of a new feature. Who: Why: The business prioritizes requests. Track the request and resulting work. Where: Story cards are seen on Kanban boards. 12

13 Kanban boards are where user stories live. 13 Here are several so you can get an idea of the variety.

14 This one has To Do, Doing, and Done. Note that someone has crossed out Done and written in Accept to indicate the the work is not really done until is has passed acceptance. 14

15 Kanban Board This is an electronic Kanban Board. 15 It is available on the web from: leankit.com for a reasonable annual subscription.

16 Kanban for Backlog You will probably need two kanban boards: one for managing the backlog and one for managing the work in progress. 16 This example shows someone`s process for working the backlog.

17 Work In Progress View Practice Just In Time Analysis and Design A deployable feature may require several components Review Above the line: Components being worked today. Below the line: Components waiting for next phase. This example shows a fairly typical software life-cycle. Analyze, Design, Build, Deploy, Review. 17 One of the key ideas behind Kanban is that it is a pull-system, not a push system. If you push stories into the work-in-progress and then you don t work them, you are increasing their cycle time and causing waste. Accordingly, Analysis and Design needs to be done just in time, and not before, to avoid having stories sitting around in inventory gathering dust.

18 To release this bottleneck, the team may need to move some resources from development and into test. Identify Bottleneck 18 Kanban boards also provide a way to spot bottlenecks in your workflow. Notice that there is currently nothing in Acceptance Test but three items waiting. There could be a good reason. For example, the acceptance test might not make sense until an entire releasable feature has been assembled. But this situation requires some attention. The bottleneck might be that your team has a bottleneck around acceptances testing. I ve seen situations where a team could not run acceptance even though the product was otherwise believed to be ready for release.

19 User Story Workshop Scenario: A legislature has decided that it wants to balance the budget. Each legislator will be issued shares of each kind of revenue to be allocated to investments and expenses. Workshop: Write user stories for this. Okay, this is where my talk gets tested. 19 We will see if I ve been sufficiently clear, and you will get a chance to try the user story technique.

20 User Story Template As a <role / persona>, I need / want a <capability> so that... <some benefit> 20

21 Details, Details, et cetera Use Case Diagrams Use Case Documents Given When Then - Clarifies Thinking Given When Then - Testable Requirements Now I will talk about ways to document the details. 21

22 Use Case Diagram A use case diagram is used to outline the situations where the system interacts with various other actors. The actors are usually humans, but may be other systems or subsystems. The egg shapes represent business tasks and are called use cases. 22

23 Use Case Diagram This use case diagram shows how various tasks are related. If may also be used to break down a task into its subtasks. 23

24 Use case diagrams can provide a big picture view. The colors might represent anything you want -- for example: What has been built so far. 24

25 Use Case Document Title: (Identify the situation or end-use.) Preconditions: (Specify context. Given ) Scenario: (Describe interaction / steps. When-Then ) Post Conditions: (Expected effects. Then ) Business Rules: (Identify policy constraints.) The use cases may be documented using a standard format. A diagram by itself is just a stage prop. Every node on a diagram should be documented before it can be considered an real design document. 25

26 Who What When Where Why - but not How User stories and use cases describe what the business wants. But you should avoid trying to include design advice about how a feature should be built in use cases and user stories. 26

27 From Story to Requirements People tend to use the words feature and requirement as synonyms. Some will say that a business requirement is fulfilled by building features. Others will say that a feature must be build to meet certain business and technical requirements. 27 I will go with the feature has requirements point of view.

28 The Given-When-Then style of writing requirements clarifies thinking. "Given" defines the preconditions that hold before an event or operation. "When" identifies an event or operation "Then" identifies the post conditions that hold after the event or operation. Given-When-Then is often the best way to identify the business and technical requirements. 28 This format tends to produce requirements that are clear to both the business and the engineers. It also may lead directly to an automated test.

29 We can apply Given-When-Then at three levels of requirements writing to document intended 1. business events (business behavior) involved at the highest level (organization/user actor) 2. user interface for business process proxies 3. code behavior at the unit-test level (robot actor). You can use Given-When-Then at three levels of thinking. 29 At the highest level, you can use Given-When-Then to identify business events. At the user interface level, you can use Given-When-Then to identify user interface behavior. At the level of unit tests, you can use Given-When-Then to specify the behavior of components. In fact, there are test libraries that enable the programmer to write unit tests in this format.

30 Business Process Level: Given:[business goal / strategy] When: [business activity / event] Then: [desired business behavior] (This can be tested by a process audit.) At the business process level your Given might be a goal, a strategy, or a prior business event. 30 The When might be an activity or a business event. The Then will typically be a desired business behavior. You cannot really write this kind of thing into software. More likely, it would be written into a procedure or policy manual. Since it is not software, the test will be some kind of process audit. The process auditor will observe the business unit in action and decide if the desired behavior is present and adequate.

31 User Interface Level: Given: [user-interface context / mode] When: [user action] Then: [system response] (This can be tested through the UI. ) At the user interface level, the Given will probably indicate the user-interface context or mode. 31 The When will almost always be a user action, but it could be triggered by some other signal. The Then will be a system response. Generally the system response will be visible in the user interface.

32 Robot / Computer Level: Given: [system state] When: [system event / input / additional state ] Then: [expected system post-condition] (This can be automated via xunit framework.) At the level of the robot or computer, the Given will specify the system state. 32 The When statements provide additional state, or identify an event or input. The Given and When specify preconditions. The Then statements specify the resulting post-conditions. In an automated test, the code under the Given will create that state. The code under When will cause the event, provide the input, or set additional state. The code under Then contains the test`s assertions.

33 At the business process level, our focus is on describing the business context of a set of requirements. Given: The survey (ballot) is published (on-line); and, the survey (voting) period is in-progress. When: A respondent (voter) enters a vote on a ballot item. Then: That vote is tallied. Then: The vote is secret. (It can be authenticated. But, it cannot be traced.) Then: The voter can audit (verify that their entry is in the collection). Here is an example using Given-When-Then to describe some business requirements. 33 Note that these descriptions indicate what is wanted without specifying how it is to be accomplished.

34 The interface level requirement identifies the interaction between actors. Typically, one actor is a user and the second actor is the system. (In an Enterprise Integration scenario, it might be two robots.) Given: The user is signed-in and authenticated and has navigated to the survey (ballot) panel. When: Some question is a proposal. Then: The allowed responses are Yes, No, and Abstain. Abstain is the default value. When you specify any kind of interface, you are, by definition specifying the interaction between actors. 34 A user interface involves two actors, the user and the system. But you can use this same procedure to specify a protocol between robots. ( between two computer systems ).

35 But we cannot write an automated test without knowing a great deal about the design. However, the design can be indicated with Given-When-Then also. Given: A ballot or survey represented in XML. When: The ballot contains a proposal. Then: The XML representation includes the pattern:"<proposal>text</proposal>". Then: The interface-builder (component) will generate user interface code (HTML) from the XML. You can also represent some design ideas using Given-When-Then. 35 As a business analyst, I am sometimes asked to record design decisions as part of the requirements documentation. Given-When-Then provides a style that adds clarity and can sometimes make design ideas testable.

36 At this point, a competent programmer can write code. The executable test might look like this (Smalltalk): test1234ballotproposalxmlgenerateshtml "The allowed responses for a proposal are Yes, No, and Abstain." ballot ballotelement proposalelement html self given: [ ballot := XML element: 'ballot' with: [ XML element: 'proposal' with: ['proposal text']. ]. "configuration comes from setup" builder := configuration interfacebuilder. ] when: [ ballotelement := ballot nextelement. proposalelement := ballotelement content at: 1. self assert: ( proposalelement istag: 'proposal' ). html := builder buildhtmlfrom: proposalelement. ] then: [ self assert: ( html includes: 'Yes' ). self assert: ( html includes: 'No' ). self assert: ( html includes: 'Abstain' ). ]. This is Smalltalk code. It is the Smalltalk equivalent of the Given-When-Then we saw on the prior slide. 36

37 Given-When-Then clarifies thinking because... In summary, using the Given-When-Then format for requirements writing tends to clarify your thinking and make the requirements more testable because... 37

38 GIVEN WHEN THEN CLARIFIES THINKING Given clause makes context and assumptions more explicit. When clause indicates when/where new behavior is expected. Then clauses indicate expected results (actions / end-states). The Given statement makes the context and assumptions of the test more explicit. 38 The When statement indicates a triggering condition or additional context where the expected result is expected. The Then clause contains the tests - the expected actions or end-states.

39 Given-When-Then Workshop Write a few Given-When-Then cards (stickies) for one of your user stories. Hints: What might the technical requirements include? What might other stakeholders require? What might the acceptance tests include? For this workshop write some Given-When-Then cards for the user stories you wrote in the first workshop. 39 Think about what the technical requirements might be. Consider what other stakeholders such as audit or information security or operations might require. Consider what the acceptance tests might include.

40 GitHub Resources GivenWhenThen See also: Here are some additional resources that I am willing to recommend. 40

41 Slideshare Resources Godfrey Nolan: Executable Requirements Antonia Marcano: BDD - beyond: Given, When, Then Louis Afredo Porras Paez: BDD for JavaScript Nickolay Vasilov: Behavior Driven Development with Java These are some additional presentations on the slideshare.net web site. 41

42 Questions and Answers - Maybe 42