|
Method Fragment:
Time-Boxed Planning + MoSCoW Prioritization |
|
|
|
|
|
|
|
|
Originating Method: DSDM |
|
|
Time-boxing is about
iterative software development, which considers fixed-time (typically 2~6
weeks) iterations periods, and plan the develoment activities in such a way
that fits the iteration period.
MoSCoW is a prioritization technique that classifies requirements into
Must , Should, Could , and Wont (or would or want to have). This
prioritization technique is usually used along with time-boxed development,
to make development cycles more flexible (not with changing the period of
development, but with dropping the less-important requirements M>S>C) |
|
|
|
|
|
|
|
|
|
Contributes to |
|
|
|
Major Softgoal |
sub softgoal |
Cont.
Value from Fragment |
Study |
Situation |
|
|
|
Improved Effectiveness (performance) |
Within-budget
project completion |
+ |
|
MoSCoW
helps projects to stay within their budget, since W req.s (those which are
nice to have) will be identified at the beginning of work, will then be
implemented if there were enough budget, otherwise dropped. |
|
|
|
Product
Quality |
- |
|
overloaded
iterations (lots of items for a fixed time iteration) and reluctant
developers who did not drop the extra items (S60: XP pays more attention to
product quality) |
|
|
|
Quick
time to market |
++ |
|
Flexible
requirements and frequent release in time-boxed development helped to achieve
quick time to market |
|
|
|
Controlled
Risks per Iteration |
+ |
|
Time-boxed
development helps to manage risks per iteration |
|
|
|
Managing
business value delivery |
+ |
|
The
use of MoSCow forces customers to specify the requirements that are necessary
for them, or these that are just nice to have |
|
|
|
Improved Communication and
collaboration |
|
+ |
|
MoSCoW
requirements prioritization encourages the mproved comm. And collab. Among
project stakeholders |
|
|
|
|
Better
understanding of customer needs |
+ |
|
MoSCoW
requirements prioritization encourages the mproved comm. And collab. Among
project stakeholders |
|
|
|
Improved Project Planning |
More realistic
priorititzation of project tasks |
++ |
|
Considering
MoSCoW rules helped to prioritize requirements more closer to their actual
business importance |
|
|
|
Flexible (yet fixed) iteration
plan |
++ |
|
Iterations
are fixed in time, but flecxible in workload (less-important tasks can be
dropped) |
|
|
|
Manageable
project plan |
++ |
|
Flexibility
of time-boxes makes them more manageable |
|
|
|
Improved
awareness of stakeholders about project plan |
++ |
|
The
use of visual time-box sheets |
|
|
|
Improved Project Management |
Better
monitoring and control of project |
+ |
|
Time-boxed
development helps to monitor and control the activities of project |
|
|
|
Improved Visibility |
+ |
|
Time-boxes
makes project progress more visible |
|
|
|
Handling Flexibility of Requirements |
+ |
|
Time-boxes
+ MoSCoW ruls helps to hamdle the dflexible requirements |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
