Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Developing User stories - Beyond the Basics

2,638 views

Published on

A deep dive into components of a user story, looking at beyond the basics that we all know (ought to know) and are familiar with. The deck provides guidance on developing individual components that make up a ‘Ready for Dev’ user story.

Published in: Software

Developing User stories - Beyond the Basics

  1. 1. @Kubairwww.shirazee.com User Stories – Beyond Basics
  2. 2. @Kubairwww.shirazee.com User Stories – more than an introduction This deck takes a deep dive into components of a user story and provides guidance on developing individual components that make up a ‘Ready for Dev’ user story. You will not need to define all the components detailed here for all your User Stories – use the common sense principle to determine the level of detail you drill down to for each User Story’s completeness
  3. 3. @Kubairwww.shirazee.com User Stories – the JEDI principle User Stories represent the ‘Just Enough Documented Information’ (JEDi) required for a cross functional agile team to understand, analyse, size, estimate, design, develop and test an independent piece of functionality that holds value for the user(s). Simplicity, independence, completeness and user value make for a good user story
  4. 4. @Kubairwww.shirazee.com User Stories – the C-Gaffsal principle Completenes s Is complete at that point in time and open to negotiation and refinements Goal Is to start a conversation with a real user Altitude Can vary (Mountain summit to grain of sand) i.e. Epic to task Format A single sentence Flexibility Is flexible to adaptation. Scope Is to create JEDI for a single activity/function Add-ons Feel free to scribble wireframe components to add visuals to the story Language Simple comprehensible
  5. 5. @Kubairwww.shirazee.com User Story – a refresher…le’format As a < role > I want < activity > so that < business value > Role - represents who is performing the action. It should be a single person, not a department. Activity – represents the action to be performed. Business Value – represents the value to the business. Why is this story important? If you are struggling to find the business value of a User Story question its purpose! It may be a task that sits within a Story!
  6. 6. @Kubairwww.shirazee.com User Story – beyond basics As a < role > I want < activity > so that < business value > Role - represents who is performing the action. It should be a single person, not a department. Activity – represents the action to be performed. Business Value – represents the value to the business. Why is this story important?
  7. 7. @Kubairwww.shirazee.com User Stories – additional components Acceptance Criteria (AC) Technical Description Decomposition: into tasks and sub-tasks (BE + FE Dev + QA) Size (Story points / T-shirt sizing / Relative Mass Valuation) Test Cases Dependencies: r e l a t e d & / o r dependent USs, PoCs, Blockers Dependencies:Frontend: Design&/orTheme UserStory:Description (US) Asa<role> Iwant<activity> sothat<businessvalue> Exception Criteria (EC) TaskHours Estimate(Hrs) Events - Sign-off from Product owner Team Consensus Recalibrate Processes and Techniques Definition of Done (Checklist) Covering These plus agreed standards That’s a Ready for Dev User Story
  8. 8. @Kubairwww.shirazee.com Specifies who does what and gains what value from the activity: the US should be: + Meaningful + Right sized for the planning stage that we are at. E n v i r o n m e n t ( H W ) , required Subs, PoCs, risks and talent required - a n y t h i n g t h a t c a n potentially be a blocker / impediment W h a t a s y s t e m should not do is as important as what it should do. The direction / options and/ o r P o C s / r e s e a r c h r e q u i r e d - n o t a decomposition exercise Recalibrate based on retrospective insights from past sprints. For example pull up 5 to 7 user stories across the size spectrum (Xs to XL / 1 SP to 8 SP) delivered, analyse variance between task hours estimates and actual task hours estimates and where a differential exists discuss why, the insight gained must be used in future sizing and estimations to improve the accuracy of the team’s sizing and estimation judgement. User Stories – additional components contd.
  9. 9. @Kubairwww.shirazee.com AC must be written by the Product Owner &/or Client side Business analyst. Where this creates a b o t t l e n e c k o r i s challenging - facilitate the process, including writing likely ACs for the story. Automate testing from the earliest sprint possible 1) automated unit tests 2) automated feature verification tests 3) automated functional/regression tests 4) manual testing.  All testing tickets on JIRA must facilitate the client side UAT process. For items deeper in the backlog, give a rough estimate. By the time the team actually begins to work on those items, the requirements may change - don’t go waterfall on sizing and estimates. Decomposed tasks and sub-tasks feed this process; it is a collaborative team exercise to build c o n s e n s u s , o w n e r s h i p a n d commitment. Don’t forget the dependencies on Front end Design and Theme layer - analyse the UX and UI requirements early on and build the timelines for their delivery & implementation in your sprint plans User Stories – additional components contd.
  10. 10. @Kubairwww.shirazee.com Hint! Setup a Skype UAT Group lead by the QA lead to walk the client side UAT lead through the process Hint! Start with Epics and work your way down the detail whilst grooming the Product Backlog Hint! Compare Estimates against baselined user stories in the PS User Story Library - its a good measure of team confidence. Hint! Establish an upper limit - e.g. no task is >16 team hours User Stories – additional components contd.
  11. 11. @Kubairwww.shirazee.com Thank you. If you got value from what I have shared please consider giving back by contributing to @BringPTP, you can follow, broadcast or donate: http://gofundme.com/bringptp Peace Through Prosperity (PTP) improves the local/domestic environment for peace by nurturing prosperity. PTP alleviates poverty through empowering micro-entrepreneurs with knowledge, skills, ability and increasing their access to income and opportunities. PTP supports small businesses, owned/managed by vulnerable and marginalized individuals/groups in society. PTP is innovating program design and delivery by using Agile design and delivery frameworks to create and deliver low cost, immediate and lasting impact programs in ‘at risk’ communities. www.bringptp.com

×