Task selection criteria
A Task is a defined piece of work to be finished within a certain time.
In the weekly TaskCycle, we use Tasks of 6 hr or less.
Tasks are defined based on highest importance.
We allow ourselves only to work on the most important things,
never on less important things
Importance, however, is determined by many things.
For example: Getting something out of your mind
may
be a good reason for getting it done. On the other hand,
it still should be really necessary to do
now.
A good question to ask is "Why is this really necessary now?" If the person doesn't know an immediate answer,
there is a good chance that other things are more important. Therefore, if you don't ask that question, we'll probably be wasting time somewhere.
Because we are short of time, we better use the limited available time as best as possible. We don't try to do better than possible.
To make sure we do the best possible, we choose what to do in the limited available time, rather than letting it happen randomly.
The following list may help to select the priority. However, this is just a start !
Don't forget to adapt this list based on your own
experience, using PDCA !
- Most important requirements first
- What has the highest value contribution
- Highest risks first
- At the end of the development you don't have time any more to cope with problems
- At an earlier stage, you still have time to find a solution
- The solution to a high risk may change the requirements or design of easier parts
- If a high risk turns out unsolvable, we better find out as quickly as possible!
- Requirements change is a known risk. Don't suppress it. Deal with it as soon as possible!
- Most educational or useful/supporting for development first, e.g.:
- Avoid wasting time on knowledge others can teach you faster than you can find out yourself
- Avoid wasting time on repetitive tasks you can automate, like:
- Automating build functions
- Automating test functions
- Synchronise with other developments, e.g.:
- Hardware may need test or verification software at a certain time
- Same for production
- Make sure hardware is available when the software needs it.
However: don't deliver the hardware too soon,
as the software people will start trying instead of designing. The longer they have to wait for
the hardware, the more they have to think to do it right the first time.
On the other hand, being late with hardware, may expose design/architectural issues too late.
Up to you to find out what is best for you.
- Every cycle delivers a useful, completed, working, functional product
- So, Tasks should contribute to this goal
- Define stakeholders for every delivery. Stakeholders may (as last resort) include yourself
- Invite stakeholders to check the validity of the requirements and evoke changes in the requirements. Changes will happen anyway.
