When I work TDD I tend to start out with the big picture and create the tests that should succeed in order for the overall assignment to be completed – it then kicks off a number of supporting classes/methods/tests as I ‘dig in’.
If my assignment has been planned out in detail, I would then open one task, and in order to solve it, open another and then another. Only when the overall tests are succeeding can I close the original task, which means that at any given time, I would have a number of open tasks.
I find that this approach conflict somewhat with the scrum approach where, ideally, I should be able to take and close a task within a day’s work – and never have more than one task open at a time.
I’m looking for input about how you manage this in your project – references to articles are also very welcome, I’m sure this has been debated thoroughly somewhere…
The ‘answer tick’ will be awarded to best comment/reference.
Thanks for any input,
Anders, Denmark
It sounds as if your tasks might be horizontally sliced – perhaps along technical boundaries like “create database table” or “write controller” – while your development is sliced vertically.
I hate having to split stories into tasks anyway (it’s useful for novice teams and to keep project managers happy, nothing else) but if I’m forced to do so I’ll split them vertically, by scenario. Take the first “happy path” through a story. Make that into the first task. Find the edge cases. Each of them becomes another task. So for instance, if I’m asked to write ATM software and the story title is “Let people take out cash”, my tasks might be:
This has the additional benefit that at any point I can showcase something and get feedback, allowing me to bring testers in early to help me work out if I’ve missed anything.