Ready to implement
…getting closer and closer to actually implementing new ideas, new features, new products.
✣ ✣ ✣
Quality in, quality out, and stability in a sprint. A smooth, sustainable and predictable product development cycle makes planning releases a breeze and both product owners and development teams shine.
A product backlog item or user story that is ready to implement gives the team confidence that every story they bring into a sprint is completely ready for them to get started on. In this way, ready to implement can improve the flow and stability in a sprint.
- it brings the product closer to the product goal;
- the product owner:
- can prioritize it;
- has quantified its value;
- knows how to demo it (prepare the demo appropriately before the sprint review meeting);
- the value of its outcome for the user (or vibrant personas) is clear, detailing how it fulfills a need, goal or desire, articulated in the format ‘As a role I want to reach some goal so that value or benefit’.; the part starting with “to…” can be put right into the user manual;
- it is detailed appropriately:
- as an enabling disclosure; and/or
- a page from the user manual, written by a mercenary analyst;
- crystal clear acceptance criteria are distilled (e.g. expressed in a domain specific language); these go hand in hand with the user manual section;
- follows the INVEST model;
- no external dependancies block the item being completed;
- non-functional criteria are clear;
- it is small enough:
- the development team:
- says “Ah, we get it!”;
- knows their implementation strategy, direction and conceptual design;
- can estimate its implementation cost in story points and have done so;
ready to implement removes a major impediment:
- Removed disruptions and waste caused by issues being clarified with customer or other.
- It’s about focus, commitment and how to share knowledge.
- Easy to address when identified.
- do not allow a feature to be included in sprint unless it is ready to implement;
- simple concept, depends on discipline and creates stability in sprint;
- prepare product backlog with at least same speed as sprints;
- clarification is a disruptive activity by nature;
- make clear arrangements for how product owner activities are supported by development team;
- balance is achieved by first ensuring that features and user stories are prepared sufficiently using these objectives
- development team proactively participated in workshops preparing sprint planning meeting
Systematically remove impediments:
- sprint retrospective at the core;
- measure and analyze data, e.g. fix-time for broken builds or flow.
Lead developers typically assist on multiple stories.
Spend about 10% of the sprint time on grooming the product backlog items into ready to implement state. Spend this time parallel to the sprint, not during the sprint planning meeting. Make it you goal to reduce the sprint planning meeting to a mere reconfirmation of the product backlog that emerged during the sprint's grooming sessions.
sprint planning meetings that spiral out of control and lively debates on particular sprint backlog items that have already been taken into the sprint are bad smells indicating the team is working on unready to implement items.
✣ ✣ ✣
✣ ✣ ✣
|Daarom in één regel||Only allow items that are really ready to implement into a sprint. +|
|Is een parel||Sprint +, Product owner +, Development team +, Ready to implement +, User store +, Product backlog item +, User story +, Product goal +, Sprint review meeting +, Vibrant personas +, User manual +, Enabling disclosure +, Mercenary analyst +, Crystal clear acceptance criteria +, Domain specific language +, Non-functional criteria +, Product backlog items +, Story points +, Ready to ship +, Product backlog +, User stories +, Sprint planning meeting +, Sprint planning meetings +, Sprint backlog items + en Sprint backlog +|
|Thema||Bouwen +, Projectleiden + en Scrum +|
|Wens in één regel||Quality in, quality out, and stability in a sprint. A smooth, sustainable and predictable product development cycle. +|