Unique specific tasks

…breaking work items into tasks.

✣  ✣  ✣

{{{wish full}}}

Remember, no guessing. We are aiming for the exact solution.

The build crew needs:

• a detailed and shared understanding of how the sprint is going to be delivered; and
• to understand what they need to modify, extend, create and delete in order to achieve the necessary results.

The tasks are just a possible side effect but not the purpose of the sprint planning meeting.

The result of a sprint planning meeting should be a list of tasks detailing how the work will be done. A good split of a product backlog item into unique specific tasks can look like:

1. Extend page flow A → B → C with…
2. Extend Service X to cope with new…
3. Sit with Domain Expert to come up with…
4. Update Repository XY with…
5. Create table A, B, C…
6. Fill table A with data from file…
7. Fill table B with data from file…
8. Fill table C with join of A and B.
9. Pair test/develop initial FitNesse tests for…
10. Create component Z for…

Therefore:

{{{therefore full}}}

✣  ✣  ✣

In scrum, if you can reuse your stickies across sprints, there probably is something very wrong with your sprint plan.

Apply one-two-automate to any repetitive work that can be automated.

✣  ✣  ✣

[[wish::Getting tasks done in a couple of hours or a day at most is fulfilling and demonstrates progress. Understanding what actually needs to be done to achieve the desired results helps hammering out details of the next greater thing you want to create. Getting a real grip on things also brings up the important questions. Answering these questions will make you feel comfortable to start working on the product backlog item because you know how.|]] Make sure your sprint plan consists of unique specific tasks.

Sources

• http://www.agilix.nl/index.php/agilixblog/123-deja-vu-what-is-a-good-sprint-plan.html

---