Jimi Fosdick, PMP, CST Agile Process Mentor jfosdick@collab.net 503.248.0800 Story Writing Basics [A user story is] a promise for a future conversation -Alistair Cockburn 1
Welcome Welcome to our ScrumCore webinar Free educational resource for the software community (and hopefully for some people in other business communities as well) Questions - I ll try to get to them! We have many people on the line so I ll answer what I can at the end I will try to touch on major topics in the follow-up email The slide deck, some answers, etc. You will hear from us within a few business days regarding these materials. 2
Who is ScrumCore? ScrumCore = Scrum 3
User Story Template As a <Some Role> I Want <Some Need> So That <Some Benefit> 4
A Real Story Card As an <unregistered user of [an online game]> I want <to setup a trial team> So that <I can try the game without signing up> 5
User Stories Should Meet the I.N.V.E.S.T Criteria I ndependent N egotiable V aluable E stimable S mall T estable * it s a word; look it up. 6
Independent Try to avoid writing user stories that are dependent upon other user stories. Prioritize dependent stories lower than the stories they depend on and cross reference. Dependent stories (if they are necessary) should NOT be done in the same sprint. 7
Negotiable Stories should describe the what, not the how The team should be able to negotiate the details (including scope) of the story User stories are intentionally incomplete and imprecise Too much detail makes a user story into a contract 8
Valuable Everything we do in Scrum should have value or we shouldn t be doing it. Identifying the value of a story is a key part of writing it. If we can t specify the value of a story we probably don t know enough about it. 9
Estimable* Stories must be something that can be estimated (E.G. make login button look cool is not estimable) A story that can t be estimated is either too vague or too large If we can t estimate a story we can t commit to it. Inestimable stories should NOT end up in our sprint backlog *It is SO a word! 10
Small Small stories are easier to estimate (and our estimates contain less error). Small stories allow more granular tracking of progress. A story that is too big to do in a single sprint is an Epic and must be broken down. 11
Testable If you can t test it, how do you know: 1.It s Done? 2.It s Right? 12
Acceptance Criteria A Definition of Done Before we can commit to a user story, we need a well-defined definition of done for each And we need a definition of done to get a more accurate size for our stories This discussion of done is one of the conversations the story represents 13
Business Criteria often forgotten degree of feature richness usability performance timing, scalability, reliability, etc. Acceptance Criteria cross-cutting concerns compliance with corporate integration needs external regulations (i.e. legal) whether/when regression failures allowable 14
Acceptance Criteria Example engineering criteria to prevent Technical Debt pair programming, code/design review manual test automated test coverage unit tests system tests prefer same language (e.g. Java, not brittle capture/playback or proprietary scripting languages) refactoring changing internals without changing behavior incrementally remove duplicate code, business logic in your presentation layer (JHTML, JSPs, etc.), complex conditional logic, poor naming, obsolete libraries... impractical without automated test 15
What Constitutes Done? At a Minimum, a story s definition of done should be: Clear and unambiguous (a 10 year old should be able to understand it) Preferably a set of binary conditions Explicitly stated (written on the story card) In particular, done should mean the value of the story has been achieved and no more work is necessary 16
Running (Tested) Features Technical Debt Robust done =Technical debt Weak done Time Waterfall 17
A More Complete Story Card Title Description Origin Size Done Criteria Simple Purchase a Round Trip Flight As a <ticket buyer> I want <to purchase a round trip flight in the simplest possible way> so that <I can be confident about using the website> Analysis of Buying and Reserving Flights, in meeting, June 14, part of Buying a Flight Backbone Large This story will be done when: -! A user can purchase an already-found round-trip ticket through the web interface -! The code has been peer reviewed -! The code is protected by unit tests, that all pass in the integrated environment 18
What do we do about Epics? Many (if not most) User Stories start out rather large As they rise to the top of the product backlog, they often need to be split into smaller stories There are many different ways to split stories depending on the nature of the story itself Some ways of splitting stories that come naturally actually undermine agility 19
Effective Ways to Split Epics Across Data Boundaries On Operational Boundaries Removing Cross-Cutting Concerns Separate Functional and Non-functional aspects Split Stories of Mixed Priority 20
Effective Ways to Split Epics Splitting Stories into Tasks Splitting Stories into Horizontal Layers Splitting Stories into Waterfall Phases 21
Don t Forget! With all this talk about breaking down epics, we need to remember that sometimes stories need to be combined. 22
Finally, a bit about ScrumCore 23
Our Clients 24
We are only a catalyst... Scrum transformations require major changes in operations and organizational culture. There is a champion behind every one of those clients someone who stuck their neck out and said, Let s try something different. Scrum transformations require major changes in operations and organizational culture. There is a champion behind every one of those clients someone who stuck their neck out and said, Let s try something different. Without clients who are passionate about what they do, the products they create, and the staff they represent, there would Without be no clients need for who our services are passionate and tools. about what they do, the products they create, and the staff they represent, there would be no need for our services and tools. We provide guidance and support to our clients through training, coaching/consulting, and a software product. We provide guidance and support to our clients through training, coaching/consulting, and a software product. 25
Basic vs. Pro 26
Want to learn more? ScrumCore is not just about selling our services and product. We also have a genuine commitment to bettering the software industry as a whole. Therefore, we make available many types of free resources to help those committed to Scrum and agile engineering. blogs.danube.com - A collection of content-rich blog posts by our Certified Scrum Trainers and other staff on Scrum topics. www.danube.com/scrum/whitepapers - In-depth discussions of important Scrum topics. www.danube.com/scrumworks - ScrumWorks Basic is a 100% free software application designed to help you manage your Scrum projects. www.danube.com/scrum/webinars/scrumcore - Webinars like this one on Scrum topics more coming soon! 27
Jimi Fosdick, PMP, CST Agile Process Mentor jfosdick@collab.net 503.248.0800 For more information please visit www.danube.com/training 28