2. ROLES
➤ Roles are people: product owner, scrum master, development
team.
➤ Development team: 3 to 9 people, whoever gets the work
done: Developers, Testers, Business analysts, DBAs, etc, etc,
etc. ( how it is possible only 3 to 9 people? ) “Self Organise”
➤ Product Owner: owns product backlog. Product Owner is one
and only one person
➤ SCRUM Master: one person, anyone but the product owner:
Facilitator, Coach.
3. EVENTS
➤ Events are Meetings & time boxes: Sprint, Sprint Planning Meeting, Daily
Scrum, Sprint Review, Sprint Retrospective.
➤ Sprint: Fixed time period, protected time boxes.
➤ Spring planning meeting: Development team decide how long the sprint
will be and what to be done in the Sprint.
➤ Daily Scrum: AKA daily stand up. Information update among the team.
Focused on the next release / spring goal. Scrum Master facilitate, but not
lead, the meeting.
➤ Sprint Review: Present the work of the sprint. Attended by all development
team, PO and anyone interested in. Update to stakeholders and gathering
feedbacks.
➤ Sprint Retrospective: Internal meeting of the development team. Lessons
learnt.
4. ARTEFACTS
➤ Artefacts are the things: Product Backlog, Sprint Backlog,
Increment.
➤ Product Backlog: Owned by Product Owner. Product Backlog
Refinement for PBI.
➤ Sprint Backlog: The amount of the user stories to be finished
in a sprint, sorted by a single priority criteria.
➤ Increment: Product Increment. Release ready final product.
5. BACKLOG & DOR (DEFINITION OF
READY)➤ Product Backlog Item/Sprint Backlog Item. PBI/SBI. Owned by
Product Owner (PO).
➤ Product Road Map.
➤ Keep the “Backlog Ready”. Backlog Refinement Meetings.
Not Officially required by the SCRUM Guide.
PO, SCRUM Master & Development Team
Discuss items on the Backlog
Estimate
Discuss Priorities & Dependencies between PBIs
Goal: Top PBIs are… Understood, Estimated, Small enough to be done in a single sprint.
Goal: 3 to 4 Sprints of “Ready” PBIs.
➤ Filled with every conceivable feature
➤ If the PBIs towards the top of the Backlog are understandable and
do-able by the TEAM in a single Sprint, those PBIs are deemed
“Ready”.
6. USER STORY
➤ User Story: a natural language description of an expected product feature.
➤ Format:
➤ On the Back, there is the Acceptance Criteria (AC).
➤ Epics & Themes
➤ IVEST: Independent, Negotiable, Valuable, Estimate-able, Small,
Testable.
➤ User Story <= Tasks.
7. ESTIMATION
➤ Estimation is something you should do as a team
➤ You’re not estimating how long it’ll take an individual to deliver
the PBI. It’s “always” the team.
➤ Story points: 1,2,3,5,8,13,21,40,80,120,infinity
➤ Story point estimation. Estimation poker. In Scrum and in story
point estimation, you’re estimating how long it takes for “THE
TEAM” to deliver the PBI to Definition of Done.
8. DEFINITION OF DONE (DOD)
➤ Definition of Done (DoD) = Everything it takes to call a feature “done”. A written
definition of done is as close as a “magic silver bullet” as you’ll find in software.
➤ A written DoD helps deflect blame and annoyance when you say “no”.
➤ A written DoD helps.
➤ The “Two Second Fix” Request.
➤ When developing your written DoD, you’ll discuss a lot more than just coding. Code
by itself isn’t that useful.
➤ Software delivery focuses on
the “big picture” of getting
software to the point that
it can actually be used.
9. VELOCITY
➤ Velocity: a mount of story points can be delivered in a single
print on average. Statics report. Planning.
13. TOOLS FOR SCRUM
➤ Tools are not important.
Physical board.
Excel
Information Radiator
➤ SCRUM has barely enough documentation.
➤ Electronic tools like JIRA: good for any teams, including
distributed teams. But it has limitations.
14. RELEASE & DEPLOYMENT, CI &
DEVOS, OH MY….➤ Automation as much as possible.
➤ Tools matter.
➤ Release and version management: git has no alternative.
➤ Automatic testing. Test Driven Development (TDD) - PHPunit, SimpleTest,
Junit, Ant, build script - it is not just unit test code. Behaviour Driven
Development (BDD) - Behat (behat.org), cucumber (cucumber.io).
➤ Version control and Release tag for production ready.
➤ Standards are very important. But needs enforceable. Thus Continuous
Integration needs support this.
➤ Environment management. Vagrant, Docker, cloud. Code first vs DB first.
Configuration as code.
➤ Push button deployment.
➤ Release management: not just code update. Release action list.