Core Scrum

descriptions and annotations

Scrum roles:
Product Owner (PO):
the one that owns functionality he/she can be the direct customer or a proxy for him (customer can be external or internal) responsible for creating and maintaining the product backlog (create user stories, set priorities)

Scrum team:

people with various skill sets that develop the product (developers, testers, it ops, BAs)

Scrum master:
scrum process facilitator it is NOT a leadership role the buffer between the development team and the rest of the world he/she protects the development team from distractions that prevent them from focusing on their work (impediments, direct outside requests) he/she ensures the scrum rules are closely followed

Product backlog:

this is basically the system's functional design in the shape of user stories it is maintained by the product owner batches of user stories are refined and estimated (roughly) by the team (taken care of by the PO or a proxy e.g. a BA) during small sessions during the sprint. This ensures the clarity of the stories and that the scrum team knows what to expect in the near future bugs should be grouped by functional modules and stories should be created for those modules (this will prevent the sprint to get polluted with bugs that don't seem to fit anywhere)

Sprint backlog:

part of the product backlog that will be delivered for a sprint

Sprint planning:
Part 1:

the PO and the scrum team sit together, detail the user stories and estimate them at a higher level (story points)

Part 2:
the team breaks the user stories into fine grained tasks and estimate them more accurately tasks that belong together will be dealt with according to priority.

Example:
User story: "As a user I want to download my invoice in PDF format" Tasks: 1. Build invoice download GUI 2. Test invoice download

this means the tester will test it as soon as it is built (environment and deployment considerations should be dealt with to facilitate this)

It's a very important part of the process as it sets the sprint's expected result

Sprint rules:
Scrum board:
the scrum master owns the board (nobody else can change anything but logging work time and assigning the story/task to themselves) pick stories/tasks from the board in order of their priority (just pick the next available one from the top down) no additional stories/tasks can be added to the board unless the PO and the scrum master (after consulting with the team) agreed upon it only minor modifications can be made to the sprint's scope (5% max)

Daily stand-up:
1. What have I done yesterday? 2. What I am going to do today? 3. Do I have any impediments? 15 minutes MAX (for the whole team). This will force the speakers to structure their thoughts better. This meeting is mostly about that: focusing your thoughts on your immediate work. You should already know what others are working on from the scrum board and also interact with them outside the daily stand-up. The POs may attend if they want to, but will not speak (dev - PO interaction should happen outside this meeting). For them is like measuring the team's heartbeat.

Impediments:

should be pursued by the scrum master by facilitating the resolution (scrum master should not pressure the impeded person to get the impediment fixed)

The development team will constantly show (or otherwise make available) their work to the POs during the sprint. This will improve the process a lot because very small and frequent changes can be made to the product as it's being built. This will also bring about quite some interaction between the scrum team and the POs (this is at the heart of Agile)

Sprint review (demo):

this should be done by the scrum team for the POs it's a discussion about the achievement of the sprint's scope and a demo of the implemented stories

Sprint retrospective:
1. What did you like? 2. What can we improve? (the "how" will be discovered with during the sprint) It forces the team to get better and better with every sprint

Short reminder of the Manifesto for Agile Software Development: We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation 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.