S is for Small.

From the outside, tech work looks deceptively easy: just typing on keyboards and sitting in meetings. From the inside, Scrum Masters and Project Managers are balancing unreasonable deadlines, remote budgets, and thorny organizational politics without managerial authority. Surviving that environment requires slicing large, overwhelming initiatives into manageable pieces. Building on our ongoing look at the INVEST model, we will explain why breaking work into small user stories is the surest pathway to project success.

The Ten Table Reality Check

The INVEST model stands for independent, negotiable, valuable, estimable, small, and testable. A good user story should have all these characteristics. When we say that a story should be small, it should be a concrete piece of work that someone can do in a single iteration.

Size, like anything in life, is relative. What may be a huge portion of work for one person is an afternoon project for someone else. For instance, the project architect created a new database for our team to implement. They provided an entity diagram with additional tables and asked us to connect them to an existing system. Their diagram was even color-coded, with blue and green tables handling the functionality. I wrote the following story.

As a developer, I want to create these additional tables in the database to support the new assessment engine functionality.

I added some basic acceptance criteria and gave it to the developers. I am used to something like this happening within an afternoon, being promoted to a development environment, and then moving to a testing server by the end of a sprint. My developers were horrified.

"This is ten tables with foreign keys to Dynamics 365," said one of the senior developers.

It seemed like a reasonable ask, but the developers kept pushing back. Since this was Dynamics 365 and we had existing data, the developers were adamant that the story was too big. After some back-and-forth, I suggested I split the story into blue tables and green tables. The developers said the work was still too big. I said I would split the stories by table and then write an additional story to make sure the primary and foreign keys aligned. After some debate, one story became twelve, and it taught me an important lesson.

When we ask for a small story, it should be small enough for the development team to complete. So, what looks like a reasonable portion of work to a stakeholder or product owner might be too much for a developer.

The Math of Kedar's constraint

The team also has a better chance of success with smaller stories. In my article about reconsidering story points, I discuss Kedar's constraint. It says that numerous smaller stories are better than fewer larger stories. Take a set of work and divide it differently. Thirty-nine story points can be divided into two combinations: three thirteen-point stories or thirteen three-point stories. Assume one story cannot be finished at the end of the sprint. You get the following situation:

People paying the bills will be more satisfied with the team's progress when stories are smaller and completion is higher.

So, smaller stories increase the chance of success and give the team more achievable goals. Next time, we'll look at the last piece of the INVEST model: testability. Share in the comments how you make stories smaller and navigate the political world of technology management.

Until next time.