Slicing up user stories into something useful has been trouble at every company I have worked with. Usually what happens is the development gets stories in various states. One story is clear cut and takes a day. The description of another story seems clear cut, but ends up taking a week or more. Product management complains that sprints are unpredictable. Each late feature cascades into the next sprint causing something, probably important, so shift off the immediate radar.
Unpredictability isn’t the problem, though. I’m not even convinced it is ‘a’ problem at this point. Unpredictability is a symptom of something going on in the organization. Luckily, it can be fixed and like with most things in life this gets easier with practice.
Most of the time, when I see this inconsistency in stories it is because there is a disconnect between the product side of the organization and the organization. The worst case of this I experienced was a company where product managers would prepare a queue of features that they though was supposed to take about a month to develop. On feature review day, the pm walked the development team through the list of features and asked if we had any questions. We always had questions, and there was only an hour to cover everything. In that time, we were usually to take one or two of the stories and break them in to smaller tasks. Maybe not small enough, but at least they weren’t a massive unapproachable blob of software. The rest of the features stayed big and ambiguous.
Product managers are busy people, and weren’t always available when we had questions. So, sometimes we built the right thing the first time, sometimes we stopped and waited for questions to be answered, and sometimes we made assumptions.
A more recent company does something interesting. The product side of the company, and the developers talk, regularly. They even sit close enough together to see each other. Product managers make an effort to split stories into something that should take a couple of days. Before the feature is developed, the dev, pm, and tester get together to review the change and ask questions. Ideally, when we start on the feature, there aren’t any surprises. Inevitably, there are surprises.
A developer starts working on something, has a piece of testable code, and then a tester looks. That is usually when questions come up. What happens if I do this, what happens when the system is in this state, should this button be enabled at this point? This is the same problem, just a little up further and with more subtle symptoms.
Luckily, that company knows what to do. The three amigos meeting (pm, tester, and developer) works because of the convergence of different perspective. Each person can ask questions the others would not otherwise be able to come up with. The solution for discovering surprise feature scope too late is exactly the same, add more perspective earlier in the process. It doesn’t necessarily have to be the people that work on the change, but someone that understands the technical stack, and someone that understands how the product will be used.
If you have unpredictability in your feature flow, look upstream. Chances are you have some gaps in communication between all the different people it takes to make a feature change.