Hacker News new | past | comments | ask | show | jobs | submit login

The problem with Agile induced "right sizing" of tasks is that you artificially split atomic units of work into multiple tickets.

A single deliverable is now 3-5 different tickets that might get split across sprints. It now becomes harder to express when a piece of atomic functionality will be delivered because you need to track with dependencies across the tickets, etc.

So it feels like contortions to make reality fit into Agile which negatively effect reality.

Let's say we are using Agile in the kitchen and we have 3 tickets - 1) research recipe, 2) collect ingredients, 3) bake cake. These are logical and understandable to a stakeholder. You can assign them different story points / sizes / durations / whatever. It's relatively easy to express the dependency and also keep it in your mental model. Each has a deliverable - 1) recipe & ingredient list 2) the ingredients 3) the cake.

However Big Agile Coach argues that really it should be 1a) research recipe, 1b) collate ingredients required, 2a) research pricing on ingredients 2b) create per-vendor ingredient lists 2c1) buy ingredients at vendor 1, 2c2) buy ingredients at vendor 2, 3a) clean kitchen 3b) prepare cake batter 3c) bake cake 3d) cake frosting/finishing

OK which of these 9 tickets depend on which / which can be parallelized / which are best to keep with a single dev, which should be done within a single sprint vs split across? Etc.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: