Smaller Stories, Agile Journeys

This is a story of one company’s continuing journey to discover agility.


Let’s pretend there’s a company that has no concept of a “Story”, small or otherwise. The description of work for the entire software product is “get it done.” Well, there are specs/etc, but you know what I mean. No part of the software is done until EVERYTHING is done. In this world, there are no stories, there’s just “The Thing You’re Working On” and the developers code like crazy until it’s done from their point of view. Then the developers “throw it over the wall” for QA to test it, and hope nothing comes back to bite them.

The result of this situation is that you can’t deliver anything until you can deliver everything. So if something changes or there’s a bug, or something is not done on time… The company is unable to deliver incremental value and they are basically sitting on lost revenue and lost feedback until they can deliver. Obviously this is not good from the company’s point of view. Can they do better?


The company then finds out about “Agile” and “Scrum.” So they start using sprints, user stories, product owners, etc, and everything is great! They even discover that smaller stories are easier to describe and easier to finish, so there is a push to make smaller stories, which is good right? That way you can develop one thing, QA it, develop another thing, QA it, and so on until the sprint is complete.

This is an improvement over waterfall, but they’ve just gone from throwing it over the wall to throwing it over smaller walls. In the beginning of the sprint, QA does not have much to do because they are waiting on development of stories to finish, and at the end of the sprint, developers do not have much to do because they are waiting on any bugs to come back and can’t start work yet on the next sprint. Can they do better?

Episode III: AGILE

Finally, the company finds out how to get the members of its co-located cross-functional teams to actually work together. With smaller well-defined stories in hand, team members with development skills and team members with testing skills are working together on Day One to get each story over the finish line. From they moment the team breaks from sprint planning to begin the sprint, they are engaged together with clarifying edge cases, coding, designing tests, more coding, writing automated tests, and even more coding. They recognize that if they have nothing to do, it’s because they’re missing something in how they should be working and collaborating in their team.


I really recommend reading “What Does QA Do on the First Day of a Sprint?” It paints what I think is a great picture with all the details about what this world can look like.

Which stage is your company in? How do developers and testers work together on your team?

Leave a comment

Filed under Software Engineering

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s