Guia PES

Development

A sprint, from planning to retrospective

PES has one inception and three sprints of about three weeks, with a single release. There is no release backlog: only the product backlog and one sprint backlog per sprint.

The four ceremonies

Start

Sprint planning

Set the sprint goal and build its backlog. The same day, planning_X.pdf goes to the Drive.

Every class

Daily scrum

At least twice a week, in class: what I did, what I will do, what blocks me. It syncs the team for the next few hours.

End

Sprint review

Show what is done, discuss what went well and which problems you solved, and revise the product backlog for the next sprint.

After the review

Retrospective

What went well, what can improve and what you commit to for the next sprint. It also reviews how you work.

Velocity-driven planning

  1. Adjust priorities and set a target velocity (from history, a prototype or an estimate).
  2. One sprint goal, in a single sentence.
  3. Pick stories by priority and effort until you reach the target velocity.
  4. Break them into tasks, ideally one day at most.
  5. Estimate the tasks in ideal hours. Roughly, the sum should match the points.

Tasks mix engineering and management (designing the UI, coding, writing acceptance tests, meetings) and are assigned dynamically by skills and availability. Every task must add value.

planning_X.pdf

Careful: the release plan does not assign people to stories, nor include engineering tasks or work order. All of that goes into each sprint plan.

Play

The task board

It helps the team self-organise and shows what is left and what is in progress. Move the tasks and watch the remaining hours drop.

Definition of done (DoD)

A story is not done when "it works on my machine", but when it has gone through the whole cycle the team agreed. For example:

specified → implemented → tested → documented → diagrams updated

Agree on it during the inception, write it in the project report (methodology) and revise it at every retrospective.

And when a bug shows up?

  • In a story still open: little effect, it is fixed within the same story.
  • In a story already closed: if it is small, just fix it; if it is costly, reopen the story (mind the points).
  • Always record them: bug management is one of the methodological aspects that get assessed.

The sprint report

Template sprints/1/nom_report_1.docx, in three parts:

  1. Introduction: summary of the sprint and the teamwork.
  2. Ceremonies: planning, dailies, review and retrospective, with the charts.
  3. Changelog: every change since the previous iteration, systematically.

Alongside it, the project report (memoria) is kept alive (requirements, methodology and technical description) and a PDF copy is saved every sprint.

Generator

The three charts in the report

Taiga draws some of them, but here you can make them with your own data and download them as PNG or SVG for the report. The data stays in your browser.

Sprint burndown

Points left at the end of each sprint day (day 0 is the total committed).

Velocity

Points completed in each sprint. It is the main tool to plan dates and scope.

Product burndown

Points left in the whole backlog at the start and after each sprint.

Remember: the burndown is not there to punish anyone. It is re-estimated every day and helps the team self-organise. If the actual line is not going down, bring it up at the daily.