There’s an old saying:
Q: How do you eat an elephant?
A: One small bite at a time.
This is very true when creating stories for your backlog.
Project managers and developers can get overwhelmed when they think about their product delivery as a whole. There’s software to code, machines to procure, testing, requirements to groom, etc. This can be daunting for any but a trivial project. There’s so much work to do, and especially with soft requirements, the stories can appear to be huge.
For example, let’s imagine the business needs to create an online system for data entry and reporting. Easy right? The stories might look like this:
- Create the database
- Create the input form
- Add report page
How would you estimate (aka. point) these stories? Anyone with more than a few years of experience knows these requirements are way too weak. Far too often, this is the level of detail provided. It’s too vague. When I get requirements like this, I attach some insanely large point value vhen I’m given a soft requirements like this. Usually: 40. This is a signal that the story needs further review by the business.
Once you get better requirements from the business you can go about estimating the story. However, that 40 you assigned earlier might now be something to large In my experience anything larger than an 3 should be broken into smaller stories.
A good project manager and development team can help you break your stories up. But let’s just take #2: “Create the input form” and an example to groom further.
- Add fields
- Add validation
- Store data
- Submit data for validation
- Submit data for storage
- Style the form
Each of these items should be it’s own story. I try hard to break stories up into pieces that can be completed by a developer in a day or less. This achieves many things:
- Keeping the developer on track
- Issues will be raised sooner (at the next standup!)
- It’s easier to balance work among developers
- Story integration is more frequent and smoother
- Code reviews are faster
- Higher likelihood of completing stories on time
- More accurate velocity
- More accurate estimation of delivery date
There are huge benefits to keeping the stories small.
A good Agile Project Manager or Coach can help you with the implementation and daily guidance needed to become a successful Agile organization. Have experiences on-site support is critical for success.
- Any story 4 points or greater should be broken up
- Break the stories into chunks that a developer can get done in a day