Agile camp storywriting
- 3. Why should I care? Why is this important? Focus on business objectives User stories are used to reflect the need required to meet these objectives Objectives Understand why in the world we us the “AS A – I WANT –SO THAT” structure Use real-life examples to help you be able to write and contribute to better stories
- 4. As A Identify the specific user Define iterations Team perspective I Want Stay away from HOW Define success – what is the true end goal or result So That Why? Provide basis for acceptance criteria
- 5. As a “USER” As a “System” As a “Product Owner”, “Business Analyst”….etc As a user, I want <insert solution here> No “so that” statement at all – frequently skipped
- 6. Product backlog item versus user story These are NOT the same thing Don’t write a user story for work that is not for the user The construct is used to help a team think through the steps
- 7. Take real-life examples and build possible improvements Table exercise Discussion
- 8. A challenge for the group: Think of at least one way you can personally use some of these examples to facilitate or participate in the daily scrum more effectively
Editor's Notes
- #3: Tools are just a bi-product Value – Individuals and Interactions over Processes and Tools Highly Interactive session
- #4: Introduce the topic – why this topic is important The user story is a totally new concept and we have to understand the basics to build understanding and eventually become really good at writing stories. Work is driven by these statements of business need – good stories make it much easier to deliver Set session objectives Understand why do we use this crazy AS A, I WANT, SO THAT structure Using real life examples, everyone should be able to leave the session able to help write better stories going forward. Provide a quick overview of how the session will go Highly interactive – speak up – questions as we go – I will look for volunteers first, but I will just pick folks.
- #5: AS A Why do we have to identify the user of the deliverable? Examples around departments, roles, internal/external…etc How it can make your story better? Can define an iteration – for this user and then others Gives team perspective for the solution I WANT Helps to ensure the story has the WHAT is needed on to try and stay away from how Starts to define success and gives you something to build on for AC Work to get to the real end goal or result SO THAT This is one of the hardest parts – we really want to get to the root of why so we can ensure our solution meets the ultimate need I WANT starts to help define AC, but this part really gets to the point Can go a long way to help define priority
- #6: Pitfalls – in real life Avoid just going through the motions – “As a user, I want this thing fixed so that it works” “As a SYSTEM” – “As a Business Analyst” – “As a Product Owner” “I want <insert solution>” No “So that” at all – often skipped
- #7: It is OK to NOT use this format when writing stories We certainly recommend it, but the point of the exercise to provide a construct that help you think about the most important info that goes in to a story
- #8: The basic exercise to be repeated until we run out of time: Ask the group for suggestions – write the story up on the board Ask teams to brainstorm ways they think the story can be improved AND/OR where the story seems to have gotten it right. Each group presents their feedback – discussion If no examples come from the group – have a set of real life examples ready
- #9: Wrap Up If you are at all convinced there may be better way here for you personally – a challenge: Think of at least one way you can personally use some of these examples to write stories more effectively. If you want – send me an email with your commitment and I will follow up with you to see how it is progressing – one on one….