Introduction to scrum from Railscamp Melbourne 2009

1. Scrum Breccan McLeod-Lundy (Certified ScrumMaster)

3. Product Owner

4. Team member

6. Prioritizes features

7. Explains features to the team

8. There can be only one

10. Commits to tasks

11. Self-manages

13. Maintains the scrum process

14. Assists with removing problems for the teams

15. Is not an interface between the team and product owner

17. Meetings of all types should be strictly time boxed

18. Releases and sprints are also timeboxed to dates.

20. In priority order

21. Can be reordered by the product owner at will.

23. Lays out goals for the project and identifies when a viable release could occur.

24. Longest meeting in the entire project. Still wouldn't normally be more than 3 hours.

25. Includes deciding 'done definition' and initial estimates on tasks.

27. Must include everything that is required for something for something to be done.

28. Would normally include testing requirements, documentation etc.

29. Some requirements can be separate tasks instead of being in the done definition.

31. Allows the product owner to fix any glaring problems in the cost benefit of how they've prioritized tasks.

32. A number of techniques are available to assist the estimation process.

34. Product owner can clarify details of features or requirements.

35. Based on an amount that they believe they can take through to done in the given time period.

36. The team commits to this work as the scope for the current sprint and moves it to the sprint backlog.

38. Tracks the tasks that are part of the sprint

41. Only team members speak

42. Consists of each team member saying: what they did in the last day, what they'll do in the next day and if anything is blocking them.

43. Can spawn followups where necessary(blocks, common tasks etc.)

45. Review status of product backlog with done tasks completed.

46. Collaborative discussion regarding what could likely come next on the product backlog with the product owner.

48. Team reviews its development process to see what they think went well and what went badly in the last sprint.

49. Suggests and adopts changes they would like to make to the approach in the next sprint to improve the development process.

51. Allow for an easy view of velocity in a project. So problems can be caught.

52. Knowing velocity makes it easier for the team to judge the number of tasks to pick up in future sprints.