The dependencies between each item, the complexity each one might involve, how risky each item is or how much certainty you have of how the item is to be implemented.
Then you start to work, one item at a time.
Once an item is implemented, you commit.
Chances are, you’ll want to implement part of an item while you’re building another.
Try to remain focused on an item.
Implementing two items at once is how you lose direction.
It’s also how you progressively add cognitive load to your brain until it’s too much.
And then you’re back to square one.
Let me try to illustrate with an example: let’s say I need to build a login page.
The list of items to be implemented that I’d write would be something like this:the email and password need to be matched against the local dbthe users need to see a web form in which they write their credentialsusers needs to be redirected to page X if login succeedsusers needs to be redirected to page Y if login failsvalidations need to be made against the written informationusers needs to be redirected to login page if there’s any errorFor each item in the list I’d create a commit.
As with most things in life, there is a balance to be found here.
You don’t want items in the list to be VERY specific and small.
You also don’t want them to be too big.
If they’re too small it’s impractical to work and separate them into different parts.
If they’re too big you’ll lack direction and you’re right back where you started.
The goal is that each item in the list carries the same cognitive load as the rest.
Ideally, each item should take more than less than 4 hours to complete.
More than that it it might get too big.
Less than an hour and it get’s impracticalIf all goes according to plan you’ll feel more productive because you’ll be more productive.
Finishing work, however small, is good for morale.
You’ll be more efficient, too, because you’ve reduced the amount of times you need to switch contexts to build a feature.
It’ll be harder to feel overwhelmed.
When you have to work on small simple tasks it’s easier to find the will to keep at it.
You don’t need to understand the whole thing.
Just the very next item on the list.
You’ll also have a safe place to go back to in case you break something.
Suddenly the db code started to fail?.no problem, reset to the previous commit and to the previous until it works.
You created a commit when it worked, right?Lastly and I can’t stress enough how important I believe this is, you’ll have more information to share with the rest of your team.
So instead of being “in the middle” of some feature, you can say you’ve solved X part of the problem and are still working on Y.
That Z parts are still pending implementation.
I’m sure the rest of the team, specially those managing it, will greatly appreciate the information and the decisions they can make based on it.
tl;dr commits are not definitive, create as many as you want as long as you have a direction.