Difference between revisions of "Unique specific tasks"

From Pearl Language
Jump to navigation Jump to search
(Zeroth version.)
m (what -> how)
Line 3: Line 3:
|theme=Agile, Scrum, Kanban
|theme=Agile, Scrum, Kanban
|context=breaking work items into tasks.
|context=breaking work items into tasks.
|wish in a single line=Feeling comfortable about how to get a thing done  
|wish in a single line=Feeling comfortable about how to get a thing done
|therefore in a single line=Split a work item into unique tasks specific to this work item.
|therefore in a single line=Split a work item into unique tasks specific to this work item.
|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 {{pbi}} because you know how.
|wish=Getting tasks done in a couple of hours or a day at most is fulfilling and demonstrates progress. Understanding ''how'' it actually needs to be done to achieve the desired results helps hammering out details of the next greater thing you want to create—the ‘what’. 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 {{pbi}} because you know how.
|background=
|background=Remember, {{p|no guessing}}. We are aiming for the exact solution.
Remember, {{p|no guessing}}. We are aiming for the exact solution.


The {{p|build crew}} needs:
The {{p|build crew}} needs:

Revision as of 13:40, 22 January 2013

…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 how it actually needs to be done to achieve the desired results helps hammering out details of the next greater thing you want to create—the ‘what’. 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