Welcome to the first IIBA NZ professional development workshop… as you might remember … in these workshops we aim to explore one technique in some depth … as much as we can in 2 hours anyway …> click for #a short story#
Since the beginning of time, since humans developed the ability to communicate and think into the future, we have evolved the ability to tell storiesOriginally this was – like the humble honey bee – to tell people where to find resources like animals to hunt and so onThis developed – with the shaman – into fables where stories gave examples of heroic behaviour or what happened to people that didn’t conformOver time this became our ability to fill our lives with as much fiction as we can handleAlongside this – our abilities to describe the factual have also developed – how many people have listened to someone recount an anecdote of what happened to them at the weekend and feel like they were falling asleep > Role play tell a boring storyHow different is it if someone tells it in an animated fashion? > Same story in a more interesting wayThis is the power of storytelling, to make the topic more compelling, to bring it alive, to flesh it out with characters and to care about what happens.,This is the essence of user stories
So what do you understand user stories to be? Facilitate a discussion – write up on white paper – this will be a prompt for what aspects of stories we want to cover laterKey points to bring out.> involve a person or role (i.e. the user)> tell you something that the person is doing (i.e. the feature)> tell you why they are bothered about (i.e. the business value)> promise to have a conversation later to get more detailAlso cover, what user stories are not:> requirements documents> use cases> scenarios
For first questions, we’re looking for topics we can write onto story cards to manage what we’re doing through the rest of the session> format of stories (CCC and “As a <> I want <> so that <>”)> knowing when we’re done (acceptance criteria)> quality of stories (INVEST)> size of stories (three bears – epics / stories / tasks)> estimation (Fibonacci)> scheduling ( release / iteration )> constraints (non-functionals)> defects> technical debt vs gold-plating> user roles and personas> techniques to gather stories> monitoring velocityAny of these that do not come up, add them yourself----------------------------For the second question, quickly get them to agree a simple system that they can work on in their teams
now we’ll put a couple of these techniques into practice straight away, because we’re going to work through the rest of this workshop using agile principlesIntroduce the WALL> Does anyone know what the columns are? Product backlog / Iteration backlog / in progress / doneMove the stories onto the product backlogExplain that before you begin you would normally have some idea of the size of the story (an estimate) which we normally do with story points, and arbitrary number equivalent to an ideal day, we’d confirm those estimates as more accurate when we plan the iterationFor the purposes of this, we’ll assume that they are all 1 story point, which will take 15 minutes, and each iteration is 30 minutes, so we should be able to manage two stories per iteration – the velocity> Click for planning iteration 1
Agree now which two stories about stories we’ll start with> Click for running the iteration
Get someone to time-keepSpeak for ‘up to’ 5 minutes on the techniqueGet them to work on it for 10 minutesCall them back togetherDo the same for the second technique> Click for retrospective
How did that goIntroduce the burn-chartPlot progressDiscuss what went well, what didn’t, and what could we do different> adapt, rinse and repeat
Second time round
Third time roundShould be the endDo they want to ‘invest’ in another iteration?