02. Scrum 101

Scrum Values

• Openness to feedback and ideas
• Focus; avoid distractions
• Respect others, even when things go wrong
• Courage to take risks and fail
• Commitment to the team and project

Lifecycle

Sprints center around the backlog; user stories and functionality that needs to be completed:

• Sprint retrospective and planning
• Collaborative development and testing (TDD)
  • Report to the team, offer help
• Sprint release; every sprint should end with a shippable product
• Sprint review meetings with the product owner

Ceremonies

• Standups (daily scrum meetings)
• Sprint planning meetings
• Retrospectives
• Sprint review meeting

Initial Startup

• Start with a vision:
  • What should it do
  • Why should it do it
  • How will it be used
  • Who will use it
  • Ask what goal for the product is in one month, one year etc.
• Refine its objectives and discuss these with the stakeholders (inc. product owner)
• Create an initial backlog filled with user stories
• Agree on working modes and standards (coding standards, communication channels, tools etc.)

Compared to kanban which is task-oriented, scrum has a larger initial phase before the first sprint.

Sprint Planning

• The backlog should be cleaned/refined by the product owner; other members may assist
• Priorities should be clearly stated
• The sprint should have a global goal; a theme which ensures everyone is targeting the same direction

Chunking stories into tasks may help with prioritization

Each implementation task should be sufficiently described: mockups, design, acceptance criteria etc.

User Stories

A promise of a conversation to be had:

• An intension of some functionality
• Conversation between the non-technical product owner and dev team
• Has acceptance criteria - don’t just tick off criteria blindly; go back to the conversation and what the product owner wants

Part 1: The What

• PO presents highest priority stories
• Ensure the team fully understands the user stories the team may commit to this sprint (plus one or two more - priorities may change so it is not necessary to understand them all)
• Estimate the complexity of each story in terms of points
• Use previous velocity (points delivered in previous sprint) to estimate amount of work that can be done
• Commit to the stories that will be taken on

Planning Poker

Uses Fibonacci-like progression (0.5, 1, 2, 3, 5, 8, 13, 20, 40, 100, ∞, ☕, ?); reflects increasing uncertainty in estimates.

Play the hands, then discuss why each person chose the value. Repeat until a consensus is reached.

For the first time the group is together, come up with a hypothetical scenario to calibrate what each number means.

NB: Don’t try and convert it to hours

NB: for large numbers, using the exact Fibonacci values makes the estimate seem more accurate than it really is.

Part 2: The How

• Break down stories into small tasks
  • Tasks should be SMART
  • Around 3 hours of work or less
  • Describe them thoroughly so that anyone in the team can do it
• Estimate task durations (in hours) collaboratively; ensure a consensus is reached
• A story is done only if all acceptance criteria are met

For the first few sprints, make an estimate and then double it; delays will cascade and affect dependent tasks.

Monitoring

• Use a burn-down chart; the estimated amount of work left over time
  • At the beginning, break down all stories into tasks and estimate the time each takes; otherwise, the chart will not be very useful
• If the sprint backlog will be finished early, estimate as a team how many more stories you can take on and contact the PO
• The PO should NEVER be surprised
  • Let PO/SM know early if the sprint backlog won’t be cleared
  • Surprise means poor communication and likely lack of alignment between stakeholders and product
• Spikes - research/experimentation into some method/technique should be time-boxed to ensure you do not waste an excessive amount of time

Standups

• Used in both Scrum and Kanban
• Must be short and straight ot the point
• Max 5 minutes/member

Every morning (if full time: 2/week for SENG302), answer three questions:

• What did you achieve yesterday
• What will you do today
• What issues are you facing
  • Don’t waste an entire day tring to solve an issue alone; ask someone

Review

• Demonstrate outcomes to the PO and stakeholders
• Follow a scenario which combines user stories that were completed in the sprint
  • Use realistic test data
• Stakeholders sign off on the functionality
• Gather feedback

Retrospective

The team discusses what happened in the sprint.

• Prefer coffee shops/break rooms compared to large, impersonal rooms
• Come prepared with issues/suggestions communicated before hand

Discuss issues about:

• Communication: within team, or with PO/stakeholders
• Processes
• Scope: clarity of product vision
• Quality
• Environment: is the team dynamic toxic?
• Skill: is training required?

Ask what are we doing well? How can we fix improve it?

Return to the next retrospective asking if improvements were made.

Bubble method: create a list of issues alone; pair with another team member an discuss. Repeat until the whole group is together.

Circle method: create a list of action items, sorting them by how well they went. Group close and related items together and fix these as a whole.

Lessons from the Tutorial

• Tasks in the story move together
  • Tick off tasks when done
• Review ACs before starting and when reviewing the story
• Each story should have a sub-group assigned to them, and within the sub-group tasks should be assigned to one or two people
  • Check the story points and its difficulty before deciding on sub-group size
  • Coordinate between sub-groups to ensure a consistent design
  • Subgroups that finish at a similar time should review the others’ work

What is Ready and Done?

Ensure all team members have the same understanding of these two words. What quality level is expected for ‘ready’ or ‘done’?

For stories, ready could mean:

• The story is given a point estimate
• Acceptance criteria are clearly defined
• Story is in the product backlog with the correct priority level
• All relevant documentation is attached
• All tasks from the story will stay in a single sprint

Done could mean:

• All acceptance tests passed
• No regressions
• Build/deployment scripts updated
• The product owner has reviewed the functionality
• End-user documentation updated