1. SWEN 302: AGILE METHODS Roma Klapaukh & Alex Potanin

2. 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

3. SCRUM BOARD Scrum boards vary – but the general idea is: Other possible columns include: blocked, testing BacklogTo DoIn ProgressDone

4. 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)

5. A CLOSER LOOK Front: As a, I want to [so that ] 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

6. 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

7. 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.

8. 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

9. 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

10. 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)

11. 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

12. PLANNING Planning is key Plan for testing! Plan only what you need to – don’t plan things you aren’t up to

13. 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

14. MEETINGS Scrum has a set of meeting that are common Team stand up Sprint review Sprint planning

15. 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

16. 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

17. 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

18. 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