Efforts are large and daunting. Tasks are small and manageable. What is the difference between complex and complicated? Why does it matter? How do we go about simplifying efforts? What does it have to do with making Sushi?

1. Efforts to Tasks
Do the breakdown!

2. Let's do big tasks!!!
BUGS!!!!

3. Why tasks?
● Specific, technical definition of what needs to be done
● Clearly defined technical end
● Contains or linked to the “complete context” - everything one needs to
understand in order to do the “work”
● Made to be finished

4. The opposite of simple?
Complicated (‫)מורכב‬ vs. Complex (‫)מסועב‬
complicated
involving a lot of different parts,
in a way that is difficult to
understand
complex
composed of two or more
parts; hard to separate,
analyze, or solve

5. Why small tasks?
● Easy to understand
● Easy to estimate
● Easy to finish
● Easy to test
● Easy to review
Easy is good?
● Simple to do
● Predictable result
● Simple to know we’re done
● Little planning required
● Atomic - shouldn’t be split further
Finish Small tasks Easily and quickly to reduce the size of the larger,
complicated problems so that we have built solutions we can put together to
reduce and eventually solve the complex problems.
Each task should be done with its own unit-tests.
Tasks have a lower limit… at some point the overhead ain’t worth it

6. Dependencies
● Tasks are split along dependency borders
○ E.g. Frontend-backend
○ Called method below its caller
○ Data-layer from Service layer and from Domain model
● Tasks with no dependencies are starters
● Tasks with external dependencies are integration points and should *only* be
about the integration. Split away the logic
● Circular dependencies mean we made a mistake
● Stories depend on the tasks that laid down the foundation for building them.
● Stories should become narrow down to an integration effort

7. Risk - enter the unknown
Unknowns are risky because they are unknown
Unknowns require research
Research is a bottomless pit
Isolate unknowns in research tasks and time-limit the
research tasks
Risky tasks have no “bump” - they just go on and on
Just stop

8. Case study: DB infra tasks plan
Goal: replace existing db and ORM so that existing features use the new database
seamlessly
Additionally: devops, automation and installation / upgrade processes must adapt
Constraints:
● Keep all application functionality
● Provide for e2e testing regression
● Unit and Integration tests should pass and verify the change

9. Case study: Analytics Dashboard
Goal: Create a dashboard with three different data-specific functional elements
Additionally: Centralised filter. Different display groupings. Find the right charts
library for ux and look-and-feel.
Constraints:
● Rely on existing, available data
● Testing charts correctness in integration tests
● Reduce & constrain the amount of data passed from server to client

10. As above, so below: stories
● Stories provide context for customer value
● They are rarely “sized to fit” our brains
● Smaller PRs
○ Faster cadence of change
○ Fewer code conflicts
○ Better isolation
Break up stories in sub-tasks or bullet lists
Provide complete units of full-stack value:
Salami-slices
Avoid incomplete of layer units: Layer cake
yes!

11. But not always!
Some things we don’t breakdown into stories: “Epic Level” tasks
1. Test plan and implementation (it’s own tree of tasks)
2. Styling of the ui (usually has to be concluded when everything is already in
place)
3. Research