M5 - MoSCoW Prioritization & Timeboxing

Question 1

MoSCow and Agile

Answer 1

Mo (must have) - typically no more that 60% effort - non negotiable

S (should have)

Co (could have) - around 20% effort

W (won’t have this time)

Project manager and Business analyst to have this discussion.

At the end of an increment, all unmet requirements are reprioritised

Question 2

Prioritising MoSCow objectives

Answer 2

A “Must Have” requirement is non negotiable and if not met, the project should be cancelled

PM and Business Analyst may challenge less obvious Must Haves

The business visionary and business ambassador have final say in prioritisation.

The business sponsor expects all must haves and most of the should haves.

DSDM recommended percentage split gives at least 20% contingency for could haves

Question 3

MoSCow in the planning process (4 key involved roles)

Answer 3

Business Roles

Work together to ensure priorities meet business needs

Solution/Technical Roles

Work together to ensure priorities are realistic and achievable

Bring to light any technical limitations

Business Analyst

Considers links between requirements and the availability of information

Helps identify viable groups of requirement

Project Manager

Ensures priorities are balances with known risks of the project

Question 4

Daily Stand up meetings (What is it, who is involved?)

Answer 4

• Key part of all Timeboxes (sets time for projects and measures what’s accomplished)
• Take place same time every day
• Are for and by the SDT to share information about project
• PM attends sometimes, team leader usually leads.

Key questions (2 mins each)

1. What have I done since last time?
2. What will I do before next time?
3. What problems and risks prevent progress for next time?

Question 5

What is a Timebox (+top tips)?

Answer 5

A period of time reserved for a project. 2 types - Free Format and Agile. Work should be done in the time allotted and reviewed afterwards. No extensions.

During foundations, the Agile PM helps the SDT agree on the length of the Timebox.

Must be:

1. Short enough to keep the team focused
2. Long enough to achieve something complete and meaningful
3. Usually 2-4 weeks

Must stop at the agreed time.

Must be open about task progression and what is “done”

• SDT must be empowered to handle any change during the Timebox without formal change control. Change control is warranted when:

Change of project breadth due to additional (or removal of) project requirements

Addition or upgrade of any of the MoSCow objectives

Question 6

What is an Agile Timebox?

Answer 6

5 distinct phases (review points for work):

1. Kick-off

• PM to check the timebox objectives and delivery plan
• Highlight dependencies
• Agree on acceptance criteria where possible

2. Investigation (10-20% TB effort)

• Understand detail of the work, assign tasks etc.
• Review dependencies, timebox plan and risk.

3. Refinement (60-80% TB effort)

• SDT works on the solution in line with MoSCow priorities
• Review at end of phase - at this stage, work should be almost ready

4. Consolidation (10-20% TB effort)

• Complete actions highlighted by refinement review.
• Check organisational standards have been met
• Complete final testing of the solution

5. Closeout

• Sign off on what has been delivered
• Review process and define what needs to be resolved for next timebox

Question 7

What is a Free Format Timebox?

Answer 7

Used by other Agile approaches like Scrum Sprint.

Used when the DSDM structures timebox format is not helpful.

Three phases:

• Kick-off
• Iterative Development
• Close out

Several number of formal or informal review points.

This format relies on the business ambassador being consistently available to provide feedback.

SDT picks up a user story or products/requirements and evolve iteratively until the acceptance criteria is met.

Question 8

Functional requirements vs NFRs

Answer 8

Functional requirements define what the solution does, not how.

NFR define how well the system does against a set of defined parameters. Describe solution attributes such as security, reliability, maintainability and availability

Question 9

User Story & User story card (INVEST)

Answer 9

A user story is a requirement expressed from the perspective of an end user goal

Hels define from high level requirement. Made up of the 3 C’s:

• Card
• Conversations
• Confirmation

User Story Card segments:

Front - Role, Requirement, problem/opportunity and business value

Back - Confirmation - questions for which the answer is ‘yes’

Good user story:

I ndependent
N egotiable
V aluable
E stimatable
S mall enough
T estable

Does not combine overlap or conflict with other stories

Confirms to organisational standards and policies

Cross referenced with other stories if several stories relate to the same feature