Small batches ensure quicker feedback
How often should I ask for feedback while building software products? Ideally, never!
Make feedback inevitable within your system, so you don’t have to ask for it explicitly. Do it on all levels.
By making stories very small, you can get feedback quickly. Frequently integrate changes to your code with the codebase. Upon each integration learn at least the following:
- Does it work?
- Does it do what you expect it to do?
- How well does it fit in the existing codebase?
Deliver continuously, make results available to relevant users instantly, and almost immediately find out at least:
- Do they find it useful?
- Is it easy for them to use it?
- What else is on their mind?
You don’t have to ask. Provide, watch, discuss, and learn.
Don’t wait for everything to be done
Do you have to wait for all these small stories to get done to ask for feedback?
You need feedback from your users, but you need feedback from your system, your process, and your tools as well.
Don’t stockpile small stories when you functionally finish them.
- Run tests on them – assert the behavior you wanted is there.
- Integrate – ensure it fits nicely with the rest of the codebase.
- Refactor – improve solution design safely.
Those are all both valuable and necessary, real-time pieces of feedback.
Deliver in small batches. Don’t wait for “everything” to be done.
Get your users to interact with the delivered stories if you can. However small those might be, learn from that interaction.
Big stories are large batches
We are not working in batches – we are delivering single stories, and they happen to be big!
If you are working on a single story that could be split into 5 smaller ones, you effectively have a batch of 5 small stories.
There is a simple remedy for that:
- Split the story into smaller ones
- Deliver smaller ones one by one as soon as they are done
- Get feedback and learn from it
Learn to recognize big batches. Big batches are not as friendly as one might assume:
- They delay feedback.
- They postpone learning.
- They increase risk.
- They are expensive.
Work in small batches. Speed up your delivery.
There is value even in the asmallest deliveries
“But my clients can’t get value if the whole feature is not delivered!”
Think of every functional path as a separate valuable path. If it has no value, why do you want to put it in the code?
On the other hand, if it is valuable indeed, how come it cannot be reviewed, tested, and potentially used by the clients?
1️⃣ What you want first is feedback about clients’ perception of usability, usefulness, and value.
2️⃣ Then you seek feedback about the actual value provided, based on data through production use.
Ideally, you would want 2️⃣ instantly, but it simply requires the product to be used first, for the value to be evaluated.
On the other hand, 1️⃣ is instantly available.
The smaller the batch, the faster the feedback.