SWEN 302:AGILE METHODS

Roma Klapaukh & Alex Potanin

SETTING UP

• Backlog – this is a list of user stories. These can be pretty course grained.

• Roles / personas – you want a clear idea of who you are targeting

SCRUM BOARD

• Scrum boards vary – but the general idea is:

• Other possible columns include: blocked, testing

Backlog To Do In Progress Done

BUT WHAT GOES ON IT?

• User stories• These should be coarse grained if they are a long way away• Fine grained if they are coming up

• Tasks• These may occur when you are breaking down a specific story to actually do

• Spikes• Uncommon and short• Don’t provide clear value to the client (e.g. research)

A CLOSER LOOK

• Front: As a <persona>, I want to <do> [so that <bacon>]

• Back: Acceptance test – how do I know I did it?

• In contrast a task is more: do X (still need a test [is possible])

• Though it is nice to avoid tasks where possible

• Spikes are for anomalous odd things that need doing

• E.g. Go read about Ruby and Python and then report back

SIZING

• Everything accessible should be sized (things on the tail of the backlog don’t need to be)

• The size reflects how long it will take to complete

• Can be very precise (e.g. hours, story points) or vague (e.g. S/M/L)

• Common Schemes:• T-Shirts• Fibonacci

HOW TO SIZE

• There’s an app for that…

• Everyone just picks a value and the team works it out

• Everyone must reveal their choice at exactly the same time (why?)

• If everyone agrees good. Otherwise highest and lowest value explain their choice and you get to discuss it. Repeat until you all agree.

SIZING FOR THE FIRST TIME

• Sizing can be hard to start with. So the sensible technique for picking some baseline values is:

• Find the smallest looking job you have in your entire list

• Assign it a size (probably the second smallest size if you have a wide range)

• Rate everything else in comparison

BACKLOG GROOMING

• Need to prioritise the stories

• Break up and size stories near the top – note that size can impact priority

• Add anything that has come up

• Ensure that stories have acceptance tests

MOVING INTO TODO - SCRUM

• Choose what you will do in advance

• Break up your time into fixed length sprints

• Have a fixed number of sizing units you can do per sprint (determined by experience)

MOVING INTO TODO - KANBAN

• Choose a maximum number of tasks to do simultaneously

• Make sure that you have more than enough work properly ranked

• When you need more work – move more into in progress from the backlog

PLANNING

• Planning is key

• Plan for testing!

• Plan only what you need to – don’t plan things you aren’t up to

RESPONSIBILITY• Own your work

• You can ask for help

• If you find bugs fix them

• Refactor when you need to, as you go

• Work is assigned to specific people – Write your name on the task when you do it

MEETINGS

• Scrum has a set of meeting that are common

• Team stand up

• Sprint review

• Sprint planning

SPRINT PLANNING

• This is essentially just deciding with the product owner what you will do this sprint

• Work doesn’t get changed within a sprint – once you commit you finish it

TEAM STANDUP

• Done standing (why?) and 15 minutes long

• All members day• What I did yesterday• What I will do today• What problems do I see that will prevent us doing what we set out to do

• No detail discussion. Problems can be added to the board and someone can be assigned to look at them

SPRINT REVIEW / RETROSPECTIVE

• Review• What did we accomplish?• What did we not finish?• Demonstrate the completed work to the client

• Retrospective• What went well?• What could be improved?

• A very short version of this is what you write about in your weekly reports

DEFINITION OF DONE

• Each team should have a definition of done

• What does a task (irrespective of what it is) need to do to be actually finished

• E.g. Pass all regression tests