Usually an hour per week of iteration–e.g. a two-week sprint kicks off with a two-hour planning meeting
Purpose: to make a sprint forecast outlining how much work the team can complete from the product backlog. That body of work then becomes the sprint backlog.
- Are stories well-defined by the product owner, designer, and the engineering team before implementation?
- Does everyone understand and live the team’s engineering values and culture?
- Are there clear definitions and requirements around code review, automated testing, and continuous integration to encourage sustainable, agile development?
- After the team completes a story, are there many bugs that surface? In other words, does ‘done’ really mean ‘done?’
The development team doesn't work through the backlog at the product owner's pace and the product owner isn't pushing work to the development team. Instead, the development team pulls work from the product backlog as there is capacity for it, either continually (kanban) or by iteration (scrum).
No more than 15 minutes!
30-60 minutes Demo new feature to teammates.
60 minutes We will focus on what went well and improvements. We will have a positive tone and try and avoid complaining.
The team needs to define what can or cannot be done in the sprint: estimated effort vs capacity. Estimation is often confused with commitments.
If estimates are used in a negative, confrontational way after the work is completed, then it’s likely that future estimates will be either be much bigger to ensure they never are wrong again or the time taken to create them will be much longer as the team second guesses itself worrying about the implications of getting them wrong.
Teams should use story points to understand the size of the work and the prioritization of the work. Story points go wrong when they’re used to judge people, assign detailed timelines and resources, and when they’re mistaken for a measure of productivity.
Don't fudge the numbers by declairing an item complete before it really is.
Estimates are mainly there to give a relative cost to tasks, allowing the PO to better prioritize and project.
People suck at estimating, and they suck at attaching hours to those estimates. But it seems we can better estimate things relative to each other.... Story points are a way to highlight the difference in sizes between features. A 5 SP feature is more than a 3 SP feature, and less than a 8 SP feature.... in time they figure out, relative to the other features, what is a 5 and a 1 and a 13. It doesn't matter how they subjectively reached that number, relatively speaking they learn to attach the same numbers to similar sized features. Once this happens people will know how much to pull into the sprint and the velocity will start to become relevant. The definition of a SP is that it's an abstract measure for the difficulty of a feature and the effort needed to build it
The product owner can use velocity to predict how quickly a team can work through the backlog, because the report tracks the forecasted and completed work over several iterations–the more iterations, the more accurate the forecast.
- Write a (short) comment when you move a ticket to another column
- Comment on the ticket when review is done