- The Agile Manifesto: the rationale behind scrum agile methodology.
- The Scrum Official Guide: maintained by the 2 framework authors up until... today (July 2013 version here).
The guide describes in merely 16 pages (!) a "new" ground-breaking framework for [software] product development. I give you the "5 lines" summary (as if it was needed):
- Pillars:
- Transparency (progress towards the Sprint Goal; definition of Ready is a transparency measure also)
- Inspection: several opportunities for inspection (events, etc), but not so many that gets in the way (of reaching the sprint goal)
- Adaption: if something is found it shall be fixed (or annotated as technical debt)
- Roles:
- PO (the owner of the product backlog; one person not a committee); can delegate but is still owner,
- SM (the facilitator; ensures scrum is understood; services to the PO, to the Dev. Team and to the Organization),
- Development Team (cross-functional, please; self-organizing - SM does not need to tell what's next): 3 to 9.
- Events: All time-boxed (fixed max. duration)
- The Sprint; fixed duration (fixed team); could be cancelled (if the sprint goal does not make sense anymore); max. 4 weeks.; if cancelled, Done items shall be reviewed all the same (by the PO)
- [Sprint] Planning: all team; choose "Ready" items from the PBL to the Sprint BL (after defining and having the Sprint Goal defined; do not choose non-ready items. Leave unplanned buffer (%); use sprint velocity from previous sprints (team DOES not change and is allocated 100%; what to do next sprint and part 2: how to do (technical aspects included); time-boxed to 8h (1 mth sprint), proportionally smaller for smaller sprints.
- Daily Meeting: 15 mins, SM and Dev. Team; if SM is not present shall delegate; optional: SM presents team progress (burndown chart) at start; each developer: what I've done, what I'll do today; what is blocking me (to be solved in 1-2 mins or at a tech meeting with relevant stakeholders afterwards); stand-up meeting.
- [Sprint] Review: all team; review US definition (including Acc. Criteria) and demonstrate that it is Done. present all "Done" US to the PO. Answer questions, interact with the software, inspect results, answer to questions. Rework could be raised - as new US (even if the story is Accepted - changed to the Closed status by the PO ideally); time-boxed to 4h (1 mth sprint).
- Retrospective: All team (w/o PO); think of lessons learned; what to start doing, stop doing (think on people, relationships, process, and tools); raise actions to fix (or study the); provide status of previous actions until closure; remember to plan for those actions to be closed also in Sprint Planning; time-boxed to 3h (1 mth sprint).
- NOT AN EVENT: Refinement, Backlog Grooming, Pre-planning meetings: Prepare US to be "Ready" (PO, SM & parts of Team); convert Epics (Themes, high level features) to "Ready" US; use planning poker estimation technique; each and every US shall respect the INVEST model.
- Planning poker estimation technique: estimate story points - cards deck or mobile app
- Definition of "Done": Transparency; informal: Definition of "Ready". All tasks that should be completed before some US can be stated at that status.
- Events sequence for 2 wk sprint: Planning, Daily(ies), Pre-Planning (several meetings, second week), Review (Demo, last 1-2 days); Retro: after Review (friday).
- 2 Artifacts:
- PBL: Contains PBI: Epics / Themes, User Stories (Drafts, Ready), other tasks (setup, documentation, ...): owned by the PO (which can delegate); is an ordered list (by priorities, at least for the items for next sprints)
- Sprint BL: Contains Ready US chosen from the PBL to fulfill the Sprint Goal + other tasks (unplanned, research spikes, technical debt, other tasks such as technical documentation tasks - not to be delivered in the increment - , etc.); the potentially shippable product increment contains the "Done" US (only those approved by PO)
- AOB:
- Research spike; technical debt; pigs and chicken, potentially shippable product increment = increment = something that can be incorporated in the shipped product.
- Burndown chart (personal and for the team): Ideal curve; Are we late? How many (hours, US) do we need to do to converge to ideal curve; estimation accuracy; important for self-control. Important to report effort daily.
- Taskboard: Ready - In Progress - Done - Closed / Reviewed (use post its on the wall if no IS is available)
- Tools to support: dash boards for auto-control; task board; storage for US; issue tracker (for other tasks/actions).
More interesting resources include:
- Scrum Glossary: https://www.scrum.org/Resources/Scrum-Glossary
- Resources: https://www.scrum.org/Resources
(2016-06-06: add. links at end)
- Scrum Glossary: https://www.scrum.org/Resources/Scrum-Glossary
- Resources: https://www.scrum.org/Resources
(2016-06-06: add. links at end)