Work Breakdown

Get Started. It's Free
or sign up with your email address
Rocket clouds
Work Breakdown by Mind Map: Work Breakdown

1. Why "small batch size" REALLY matters?

1.1. early feedback and visibility

1.1.1. customer

1.1.2. technical

1.1.3. address risks early

1.1.4. challenge unvalidated assumptions

1.1.5. early course correction

1.2. early benefits

1.2.1. learning

1.2.2. financial

1.3. problems are localised

1.3.1. minimise blast radius

1.3.2. reduce integration/defect effort

1.3.2.1. The smaller the batch size, the sooner errors are caught and the easier the integration is

1.4. less likely to change/evolve while 'In Progress'

1.4.1. less context switching due to less likely to be blocked

1.5. More likely to deliver to Iteration timeboxes

1.5.1. E.g. Fill a space with sand versus filling it with rocks

2. Why it matters now?

2.1. we will get there once we have automated testing, continuous integration, <add favourite valid excuse>, etc.

2.1.1. make the 'pain' real and unavoidable to fix

2.1.1.1. otherwise it'll get deprioritised into 'good enough for now' land...

2.1.2. you get better at those things that you do often

3. Why vertical over horizontal slicing

3.1. Deliverable

3.2. Prioritisable

3.3. Exposes risks of end-to-end delivery

4. Strategies

4.1. https://medium.com/@chrisverwijs/10-powerful-strategies-for-breaking-down-user-stories-in-scrum-with-cheatsheet-2cd9aae7d0eb

4.2. Mike Cohn SPIDR

4.2.1. Five Simple but Powerful Ways to Split User Stories

4.2.2. poster

5. tips

5.1. progress should be defined in terms of customer outcomes, not tasks, so slice work vertically not horizontally as much as possible

5.1.1. ideally all story/customer request cards are thin vertical slices (under 3 days of work); if that's the case, no need for further task cards

5.1.2. beware of confusing being busy with progress

5.2. If MoSCoW is not helping you, try "if you only could have ONE thing, what would it be?" approach to conversations with customers

5.2.1. discuss the options (diverge)

5.2.2. discuss co-existence needs as well (with existing systems as a means to deliver incrementally deliver)

5.2.3. discuss risks of not delivering it incrementally

5.2.4. address concerns of customers around incremental change and any tendencies to not want to see it until it's all done

5.2.5. address advantages of co-creation versus "bar service" model

5.2.5.1. our goal should be to make our customers better at their job, not just give 'em what they want (or more likely what they think they want)

5.2.5.2. the insight of and diversity of thought in the team, as a co-creation exercise is a key success factor in finding solutions that are cheaper and better than the "requirements"

5.2.5.3. pitch it as co-creation, rather than questioning their authority on why they want something

6. Related to DoD

7. structure/terminology

7.1. project/initiative

7.1.1. MVP

7.1.1.1. feature

7.1.1.1.1. (epic)

7.2. theme