2. AGILE MEANS VALUING…
1. Individuals and interactions over processes and tools
2. Working software over comprehensive documentation
3. Customer collaboration over contract negotiation
4. Responding to change over following a plan
That is, while there is value in the items on the right,
we value the items on the left more.
4. SCRUM BASICS
• A software product should be developed
• by a self-organizing team
• in multiple fixed-length sprints
• in full collaboration with the product owner
• using Agile values and principles throughout.
12. 2. BREAK UP THE SPRINT PLANNING MEETING
•Do before sprint planning:
•retrospective
•stakeholder demo
•planning poker
•Do immediately after sprint planning:
task breakdown
14. 4. CONSIDER SHORTER SPRINTS
•Your sprint may be too long if…
• Your product owner can’t wait till next sprint for
important changes, OR
• Any individual is working on more than one “big
thing” in a sprint, OR
• At the end of the sprint, there’s too many things to
keep track of, OR
• You can’t get sprint planning done in one day
•Tackle 2/3+ of the work in 2/3 of the time
15. 5. ADD SPECIALIZED DEMOS AS NECESSARY
The Sprint Demo is for the main stakeholder(s) and
should be tailored for them
If others need a more technical or more detailed
demo, do it another time.
16. 6. REMEMBER THE POINT OF OUR RITUALS
The purpose of… Is…
Product backlog
grooming/prioritization
Ensure the team works on only the most important
things all the time
Sprint planning Get a sprint backlog that the team can complete
Retrospective Find a few key areas to proactively improve
Task breakdown Understand scope of work and plan as a team
Planning poker Estimate complexity of work for prioritization
Daily scrum For the team to collaborate and clear each other’s
roadblocks
Sprint demo Deliver to stakeholders and gather feedback
18. 7. LIGHTNING ROUND
• Story points are abstract—can’t convert to hours/days
• Embrace their abstract, relative, floating nature
• …or just go ahead and estimate in hours/days
• We are making software, not code: Find some key team
members to help the Product Owner groom the backlog
• Actually stand up in the daily scrum
• Come up with big, strange, or helpful ideas within the team
• Scrum only works if everyone on the team is trying hard
still love this format,
brings out a lot of important discussion
makes the product owner consider unknown aspects of the story
Caveat: business has to be okay with fixing a narrow technical problem, not an overall user experience
The goal of sprint planning is to get a sprint backlog and thus give the team everything they need to start and complete the work.
Tasks should be completeable in a day
Real benefit happens when tasks are finished, not when they are “half done” (count tasks remaining rather than hours remaining)
Task list is for the team to self-organize around
hard to schedule meetings, get time of business
2. Find some key team members to help the Product Owner groom the backlog
and understand the tech side of planning