I was watching a sprint planning session when I first noticed the spreadsheet. The product owners (yes, two) scrolled through an Excel sheet where each row was a story: a long cell for the description, and an even longer cell for the acceptance criteria. I had joined this team as an agile coach to be a fly on the wall first, sitting in on their planning, reviews, and retros. What I saw in that spreadsheet told me a lot about the application before I ever looked at the code.
The acceptance criteria read like use cases from my waterfall days. The user clicks this button. The system presents the following form. The user fills out field A, field B, and field C auto-calculates from A times B. The team then sized these stories, and I started seeing a pattern. Five fields added to a screen meant an 11-point story. Two fields meant five points. They were estimating by counting fields.
Two Captains on One Boat
Before I got to the code, I also saw another problem. This team had two product owners because the organization believed they shared the same vision. From the outside, that seemed reasonable. From the inside, it looked like a boat with two captains. They agreed on parts of the direction, but in planning they argued over priorities and pulled the team in different directions. The developers could not follow both visions at once, and the confusion showed up in the backlog before it showed up anywhere else.
The Field-Count Trap
At first the field-based sizing looked like a harmless shortcut. If you add more things to a screen, the story gets bigger. But I had not seen the application yet, and the spreadsheet already painted a picture. The descriptions were so screen-focused that I could almost see the UI in my head. When I finally joined the developers to watch them work, my suspicion was confirmed.
The application was a CRUD interface that had grown to look and feel just like Excel. Screens had dozens or even a hundred fields. The business analysts thought in terms of screens and fields because that is what they could see. The developers were trying to size in those same terms because that is what the stories gave them.
One Field, Thousands of Lines
Once I saw the code, the problem became clear. On a screen with a hundred fields, adding one more field could mean touching thousands of lines of convoluted logic. The new field might be freeform informational text or an image file attachment, something that should not trigger any calculation. Yet populating it ran through slow code, multiple database queries, and a cascade of unrelated rules.
The developers did not fully see this because they were used to the code. The business analysts did not see it because the field looked like every other field on the screen. When a developer said one more field made the story big, the analysts accepted it. Nobody was translating the real cost between the two worlds.
Sitting in the Middle
That is where being the person in the middle helped. I could talk to the developers about the code and to the analysts about the workflow. I could point at a field and ask why this piece of freeform text needed to run through the same heavy calculation as the rest of the screen. Once both sides saw the disconnect, the conversation changed. The analysts began to understand why a one-field change could be expensive. The developers began to see that the screen was not the workflow.
Sprint after sprint, the communication improved. The team started designing around what people were trying to accomplish instead of counting how many fields they were told to add. They began to see the screens as symptoms of workflows, not as the requirements themselves.
The Lesson
It is easy to size a story by what you can count on the screen. It is much harder to size it by the hidden cost underneath. The real work of coaching that team was not teaching a new estimation technique. It was building a bridge between two groups who were speaking different languages about the same application. Once they understood each other’s view of the work, they stopped counting fields and started solving the actual problem.
Leave a Reply