I?ve talked about why smaller is better and especially why this pertains to product backlogs, or rather fatlogs, but I wanted to zoom in for a second to one of the most valuable applications of the rule: writing the code.
Typical workflow
What do you do when you get a task or a backlog item to work on? Do you just pick a starting point and start writing code? Do you break it down into a few pieces and start working on one?
It probably depends on the size of the work.
When I run into an item that is sized a little too large, problem admiration can set in if I am not careful.
What is problem admiration? It is when the problem you are trying to solve seems too big and overwhelming, that you just sit and stare at it instead of attacking it.
This can be a really big problem if you don?t have a good workflow that tackles it.
Winning the battle
So how do we combat this problem?
One of the strategies I use, is very similar to a mini-agile process in the agile process.
When I am working on a piece of functionality, I will have my own sticky notes nearby.
I?ll slice up my work, whether it be a task or a backlog, into distinct pieces of work that need to be done. I?ll even write a few different units of work on a single sticky note.
I might have a sticky note that says ?localize the screen.? Or one that says ?recheck unit tests to make sure they are accurate.? Or ?Populate drop down x.?
Sometimes I refine the notes and break them down further. My goal is always to get the current task at hand to such a small difficulty that I can easily accomplish it.
You are always much more effective doing many easy tasks rather than trying to do few difficult tasks.
As I accomplish a task, I cross it off the list.
If I think of a new task, I add it to the list.
Why is this so important?
In general, developers, or rather humans, share a weakness of having a hard time accomplishing something that is large and not fully understood.
I have seen some very knowledgeable and skilled developers that were never successful, because they could never push through and get things done.
Time and time again I have seen them become paralyzed by the work that needed to be done instead of actually doing it.
You might not have this problem in general, but you would probably be lying if you said you don?t suffer from it from time to time.
You might not even recognize it. It might show up as a lack of motivation, or ?burn out.?
Many times when I don?t break down the tasks into smaller pieces I have a tendency to overlook some part of the work that needed to be done, because I either forgot about or didn?t take the time to consider it.
If you take the time to break apart your work into very small pieces, you will probably find, you are more motivated to get the work done, feel like you have a better direction in which to go, and will miss fewer requirements.
Well said!
And I´d like to add: Whenever possible try to break the feature you´re supposed to implement into slices. Slices are parts of features which still deliver some value to the “customer” (be that a user or another functional unit).
Try to accomplish as much as possible in slice-wise. That way you can always deliver something.
-Ralf
Can’t agree more with you.
At the beginning of an iteration we developers get together and for each story think of tasks that needs to be achieved. We then put it on a our task board under to-do section. The collective intelligence allows us to come up with as many tasks as possible for a story. This also allows us to think of areas which were not included in the story as part of acceptance criteria. As the story progresses the developer(s) working on the story further adds tasks.
You have very accurately described the condition I find myself in at the start of new work. I too start looking for small tasks to do, for me this is usually tests to write. I will try your technique next time. Thanks for the article.