swdev:agile:scrum_implementation [Audina Documentation]

Easy steps to implement SCRUM based on Kelly Waters' How To Implement Scrum in 10 Easy Steps.

Align with Business: At least one person per product (if supporting multiple products).
Start with Business as Usual: Use a project in bug fixing and enhancements cycle.
Find a Willing Product Owner: One person responsible for prioritizing on the product.
ScrumMaster: One person supporting the Scrum Team, removing obstacle blocking progress.
Create Product Backlog: A list of things to be done to product, in priority order (expressed in business terms, not technical). It can contain anything: bugs, enhancements, whole projects, issues, risks, etc.
Prioritize Backlog: Only the Product Owner can prioritize the Product Backlog.

Estimate in Points.
Use a Point System: Eg: Fibonacci numbers: 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, 144, 233, 377, 610, 987… Typically just 1 - 21.
Estimate as a Team. Each member offers an estimate.
Review Priorities.

Sprint meeting: all developers, testers, and product owner involved. All roles must be included.
Decide sprint duration: 1 week, 2 weeks, 1 month (recommended).
Keep Sprint Duration Consistent.
Select Target Backlog for Sprint: pick a section of items/features from the top of backlog that can be achieved in sprint. Include stretch tasks, which are items to tackle if sprint finishes early.
Clarify Sprint Requirements. Discuss and write down each requirement feature by feature. Write user stories: As a [type of user], I want to [do whatever], so I can [achieve some goal]. The story can be described by a UI sketch.

Sprint meeting: all developers, business analysts, testers. Product owner and customer do not need to attend.
Set Sprint Budget: number of hours required for sprint. Deduct from total man-hours available for sprint.
Break Requirements into Tasks. Tasks can be: Design, Development, Unit Testing, System Testing, UAT (User Acceptance Testing), Documentation, etc. State tasks as deliverables.
Estimate Tasks in Hours. Ideally a task would be less than 1 day. Breakdown large tasks if necessary.
Commit to the Sprint Backlog. If all tasks add to more than alloted sprint, then remove lower priority tasks.
Identify Stretch Tasks. Tasks that can be tackled when team delivers early, in order to keep sprint a fixed length.

Whiteboard your walls.
Create a place for collaboration. Whiteboard is the collaboration hub.
Management by post-it note.
- Whiteboard with 5 columns: columns: Product Backlog, Tasks To Do, Work In Progress, Ready To Be Verified, and Done.
- Use notes with Backlog Items (and all tasks listed for that Item), and place them in 'Product Backlog'.
- Use notes with Tasks, and place them in 'Tasks To Do', then move as needed.

Develop, implement, test, etc. as necessary to finish a Task.
Testing is part of lifecyle of each Sprint.
No interference. Changing priorities mid way adds double the time to new task that caused disruption.
Aborting a sprint should be reserved for rare cases. You must go back to sprint planning at this point.

Hold a daily stand-up meeting.
All must be present (non-optional), including product owner and active customers, and users.
Semi-circle around whiteboard.
Each member reports to team. Person reporting is the only one speaking. Report should be concise and focused. Must address 3 questions:
- 1. What have they achieved since the last meeting? (yesterday)
- 2. What will they achieve before the next meeting? (tomorrow)
- 3. Is anything holding up their progress? (impediments)
Quick questions can be raised, but discussed with revelant people after scrum meeting.
Scrum Master facilitates the meeting, keeping time, on topic, no obstacles. Impediments are noted on the whiteboard to be dealt later by Scrum Master or delegate.
Meeting must be held the same place, same time, every day, routinely, at a time all members can attend.
Penalty for late arrival to meeting (like $1), to be later spend at end of sprint.
Stay focused, avoid overrun, since all members are present and it is expensive. Typically 15 min should work for large teams.

Update the estimated time to complete (ETC) each task on a daily basis.
Each team member can be responsible for updating their own ETC’s on a daily basis before the Scrum.
Plot progress visually on a line graph.
- Series 1: Original Estimate.
- Series 2: Current Estimate.
Annotate with key events, describing key events along the way.
Scrum highlights your problems – it doesn’t solve them. You get the true picture.

When sprint is completed, those tasks are 100%, allowing to ship when time is up.
All changes must be reversible, to make sure you can always ship in case something goes wrong.
Complete each feature before moving to the next.