Project Management
Tutto può accadere in uno Sprint
“Preparazione Esame di Certificazione Agile PMI-ACP®“
Everything Happens Within a Sprint
Articolo tratto da: Monthly News from Mike Cohn and Mountain Goat Software del 3-12-2013
Riporto integralmente un articolo di Mike Cohn per la sua capacità di sintesi e per l’efficacia della formula utilizzata nel parlare di Sprint. Buona lettura.
Should bug fixing happen in the sprint or outside it? What about user interface design: Should that happen in sprints or outside them? Are the sprint planning meeting, sprint review and retrospective part of the sprint or do those meetings happen outside the sprint?
I’ve been asked a lot of questions like those. Fortunately the answers are easy: sprints run back to back so there is no “outside the sprint,” meaning that everything happens within a sprint.
Sure, some things may happen this sprint so follow-on work can happen next sprint, but it all happens within a sprint. To clarify this, let’s specifically consider the three questions above, starting with bug fixing.
When I’m asked about bug fixing, normally the question refers to bugs found in this sprint but created during some earlier sprint. It doesn’t matter whether the bug is reported by a user or found by a team member. The product owner will need to decide if the bug is worth interrupting the work of the current sprint. This should be done as infrequently as possible. But it will happen occasionally for most teams. Such teams usually then plan for it by reserving some amount of time each sprint for emergency bug fixes.
So, bugs can be fixed in the current sprint or deferred until a subsequent sprint based on their criticality. But either way, they are fixed within a sprint, not outside one.
What about user interface design? Ideally user interface design happens within the same sprint as the rest of the development work occurs. That is, while a programmer is coding and a tester is testing, a user interface designer is working out the details of the user interface.
This isn’t always possible, though, and sometimes some user interface design is done a sprint (or even two) ahead. But that work is done within a sprint. It’s not treated as some magical thing that is allowed to happen “outside a sprint.” A key consideration here is that any design work that occurs ahead of the rest of the development work should be done as little ahead as possible and in as little detail as possible. In other words, as much as possible should be done during the sprint when the rest of the team is working on the product backlog item.
Finally, what about meetings? The question I’m really being asked about meetings is whether a two-week sprint is really ten days of work or is it more like nine-and-a-half days of work plus a half-day lost to planning, review and retrospective meetings. These meetings are definitely part of a sprint; they do not occur “outside” the sprint. Usually it’s best to think of the sprint as officially starting as soon as the planning meeting begins and ending after the latter of the review or retrospective.
As you can see from these examples, everything occurs within sprints. In general, there is no “outside the sprint” to even consider. (Fonte: Mike Cohn). “