User stories
Upcoming SlideShare
Loading in...5
×
 

User stories

on

  • 913 views

User Stories presentation given to Agile Groupies meeting on

User Stories presentation given to Agile Groupies meeting on

Statistics

Views

Total Views
913
Views on SlideShare
913
Embed Views
0

Actions

Likes
0
Downloads
18
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

CC Attribution License

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    User stories User stories Document Transcript

    • User StoriesWednesday, January 23, 13 1
    • User Stories and their friends: Use Cases, Scenarios, Personas, Gherkins and Kanbans Who writes user stories? 7 W’s 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?Wednesday, January 23, 13 2Whenever you want to explain something, it is often useful to consider the W’s.Who, what, when, where, why start with W.How does it work?How much . . .?The How’s end with W.
    • A user story identifies an idea.Wednesday, January 23, 13 3A user story identifies an idea.
    • 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.Wednesday, January 23, 13 4What is it?Here is the standard template for a user story.The purpose of a user story is to serve as a reminder to have a deeper conversation with theuser later.The card or sticky-note provides a place-holder in the backlog.
    • User Story What, When, Where, Why, Who • What: Short description of a want/need. • When: Someone (?) thinks of a new feature. • Who: The “business” prioritizes requests. • Why: Track the request and resulting work. • Where: Story cards are seen on Kanban boards.Wednesday, January 23, 13 5What is it?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.
    • 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.Wednesday, January 23, 13 6Here is an example of a user story.It has its own W`s - What is wanted by whom and why.
    • When someone thinks of a new feature.Wednesday, January 23, 13 7You can write a user story whenever anyone things of a new feature.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.
    • User Story What, When, Where, Why, Who • What: Short description of a want/need. • When: Someone (?) thinks of a new feature. • Who: The “business” prioritizes requests. • Why: Track the request and resulting work. • Where: Story cards are seen on Kanban boards.Wednesday, January 23, 13 8The best time to record a user story is when it is first suggested.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.
    • User Story What, When, Where, Why, Who • What: Short description of a want/need. • When: Someone (?) thinks of a new feature. • Who: The “business” prioritizes requests. • Why: Track the request and resulting work. • Where: Story cards are seen on Kanban boards.Wednesday, January 23, 13 9The business is responsible for providing priorities.When there are several business stakeholders with differing priorities, you need a way to sortthings out. Use a long table or wall where the business representatives can sequence thestories from low value to high value so that the highest value stories can be worked soonest.
    • Business prioritizes user stories in the backlog.Wednesday, January 23, 13 10
    • User Story What, When, Where, Why, Who • What: Short description of a want/need. • When: Someone (?) thinks of a new feature. • Who: The “business” prioritizes requests. • Why: Track the request and resulting work. • Where: Story cards are seen on Kanban boards.Wednesday, January 23, 13 11User stories provide a way to capture feature requests in a reasonably clear style.Once captured you can use any requirements management system.But, most agile folks prefer Kanban boards.
    • User Story What, When, Where, Why, Who • What: Short description of a want/need. • When: Someone (?) thinks of a new feature. • Who: The “business” prioritizes requests. • Why: Track the request and resulting work. • Where: Story cards are seen on Kanban boards.Wednesday, January 23, 13 12
    • Wednesday, January 23, 13 13Kanban boards are where user stories live.Here are several so you can get an idea of the variety.
    • Wednesday, January 23, 13 14This 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 untilis has passed acceptance.
    • Kanban BoardWednesday, January 23, 13 15This is an electronic Kanban Board.It is available on the web from: “leankit.com” for a reasonable annual subscription.
    • Kanban for BacklogWednesday, January 23, 13 16You will probably need two kanban boards:one for managing the backlogandone for managing the work in progress.This example shows someone`s process for working the backlog.
    • Work In Progress View Practice Just In Time A deployable feature may Review Analysis and Design require several components Above the line: Components being worked today. Below the line: Components waiting for next phase.Wednesday, January 23, 13 17This example shows a fairly typical software life-cycle.Analyze, Design, Build, Deploy, Review.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 avoidhaving stories sitting around in inventory gathering dust.
    • Identify BottleneckWednesday, January 23, 13 18http://ketiljensen.wordpress.com/2009/10/31/kanban-the-next-step-in-the-agile-evolution/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 untilan 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 wasotherwise believed to be ready for release.To release this bottleneck, the team may need to move some resources from developmentand into test.
    • 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.Wednesday, January 23, 13 19Okay, this is where my talk gets tested.We will see if I’ve been sufficiently clear,and you will get a chance to try the user story technique.
    • User Story Template As a <role / persona>, I need / want a <capability> so that . . . <some benefit>Wednesday, January 23, 13 20
    • Details, Details, et cetera Use Case Diagrams Use Case Documents Given When Then - Clarifies Thinking Given When Then - Testable RequirementsWednesday, January 23, 13 21Now I will talk about ways to document the details.
    • Use Case DiagramWednesday, January 23, 13 22A use case diagram is used to outline the situations where the system interacts with variousother actors.The actors are usually humans, but may be other systems or subsystems.The egg shapes represent business tasks and are called “use cases”.
    • Use Case DiagramWednesday, January 23, 13 23This use case diagram shows how various tasks are related.If may also be used to break down a task into its subtasks.
    • Wednesday, January 23, 13 24Use case diagrams can provide a “big picture” view.The colors might represent anything you want -- for example: What has been built so far.
    • 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.)Wednesday, January 23, 13 25The 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 designdocument.
    • Who What When Where Why - but not HowWednesday, January 23, 13 26User 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 inuse cases and user stories.
    • From Story to RequirementsWednesday, January 23, 13 27People 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 technicalrequirements.I will go with the feature has requirements point of view.
    • 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.Wednesday, January 23, 13 28Given-When-Then is often the best way to identify the business and technical requirements.This format tends to produce requirements that are clear to both the business and theengineers.It also may lead directly to an automated test.
    • 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).Wednesday, January 23, 13 29You can use Given-When-Then at three levels of thinking.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 ofcomponents.In fact, there are test libraries that enable the programmer to write unit tests in this format.
    • Business Process Level: Given:[business goal / strategy] When: [business activity / event] Then: [desired business behavior] (This can be tested by a process audit.)Wednesday, January 23, 13 30At the business process level your Given might be a goal, a strategy, or a prior businessevent.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 desiredbehavior is present and adequate.
    • User Interface Level: Given: [user-interface context / mode] When: [user action] Then: [system response] (This can be tested through the UI. )Wednesday, January 23, 13 31At the user interface level,the Given will probably indicate the user-interface context or mode.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 userinterface.
    • Robot / Computer Level: Given: [system state] When: [system event / input / additional state ] Then: [expected system post-condition] (This can be automated via xUnit framework.)Wednesday, January 23, 13 32At the level of the robot or computer,the Given will specify the system state.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.
    • 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).Wednesday, January 23, 13 33Here is an example using Given-When-Then to describe some business requirements.Note that these descriptions indicate what is wanted without specifying how it is to beaccomplished.
    • 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.Wednesday, January 23, 13 34When you specify any kind of interface, you are, by definitionspecifying the interaction between actors.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 ).
    • 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.Wednesday, January 23, 13 35You can also represent some design ideas using Given-When-Then.As a business analyst, I am sometimes asked to record design decisionsas part of the requirements documentation.Given-When-Then provides a style that adds clarityand can sometimes make design ideas testable.
    • 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 ). ].Wednesday, January 23, 13 36This is Smalltalk code.It is the Smalltalk equivalent of the Given-When-Then we saw on the prior slide.
    • Given-When-Then clarifies thinking because . . .Wednesday, January 23, 13 37In summary, using the Given-When-Then format for requirements writingtends to clarify your thinking and make the requirements more testable because . . .
    • 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).Wednesday, January 23, 13 38The Given statement makes the context and assumptions of the test more explicit.The When statement indicates a triggering condition or additional context where theexpected result is expected.The Then clause contains the tests - the expected actions or end-states.
    • 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?Wednesday, January 23, 13 39For this workshop write some Given-When-Then cards for the user stories you wrote in the first workshop.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.
    • GitHub Resources • https://github.com/RichardAlexanderGreen/ GivenWhenThen • See also: • https://github.com/KentBeck/TDD-Tyrant • https://github.com/pivotal/jasmineWednesday, January 23, 13 40Here are some additional resources that I am willing to recommend.
    • Slideshare Resources • Godfrey Nolan: “Executable Requirements” http://www.slideshare.net/godfreynolan/net-executable-requirements • Antonia Marcano: “BDD - beyond: Given, When, Then” http://www.slideshare.net/RiverGlide/bdd-beyond-given-when-then • Louis Afredo Porras Paez: “BDD for JavaScript” http://www.slideshare.net/lporras161/jasmine-bdd-for-javascript • Nickolay Vasilov: “Behavior Driven Development with Java” http://www.slideshare.net/shadrik/bdd-with-java-8323915Wednesday, January 23, 13 41These are some additional presentations on the “slideshare.net” web site.
    • Questions and Answers - MaybeWednesday, January 23, 13 42