2024 Public Training Schedule
December 9 – 12, 2024 – Agile Analysis and Design Patterns
Half-Day Sessions
Follow me on Twitter:
Blog Post Categories
- Announcements {19}
- Articles {2}
- Bits and Pieces {74}
- Blogosphere {1}
- Bonuses {2}
- Build in Small Batches {27}
- Collaborate {38}
- Create CLEAN Code {34}
- Implement the Design Last {11}
- Integrate Continuously {30}
- Off-Topic but Interesting {3}
- Rants {82}
- Refactor Legacy Code {24}
- Say What, Why, and for Whom Before How {22}
- Seven Strategies {38}
- Specify Behaviors with Tests {17}
- Write the Test First {27}
Archives
Privacy Policy
(c) 2024 To Be Agile
- August 17, 2016
- Build in Small Batches
A number of Agile methodologies rely on artificial time boxes such as sprints or iterations. The purpose of these time boxes is to get you good at breaking down work so you’re only building a small piece of functionality at a time.
One of the critical skills in Agile development is being able to split up stories so they’re easy to build then assemble later. Small units are the core of all Agile practices so getting good at splitting stories is critical for being able to take best advantage of the Agile software development process. This is not some form of black magic nor is it a string of lucky guesses. Time boxing is a set of skills that, like all skills, need to be practiced to be mastered.
The goal is to build small units of value that we can deliver frequently to our customers. This should take place as we’re building features. Each task and each step in each task should be optimized so it provides maximum value as quickly as possible. The smaller the units we can work in that still deliver value, the better. Working in small units means we get feedback faster.
There are lots of techniques for splitting stories. Ideally, we like every story to just require one to four hours of effort to complete. But some teams starting out with these practices have a hard time imagining how they can create value for their customers in less than half a day’s work.
But always keep in mind that when splitting stories for development you don’t have to produce a complete, major feature. Ideally, we like to break down major features into a series of smaller features. Sometimes this is practical, in some situations it’s not. But in most situations Pareto’s Law does prevail and 80% of the value can be found in 20% of the effort—so it’s a good idea to identify what that 20% is and work to accomplish that first.
Previous Post: « Technically Speaking Podcast
Next Post: Story Splitting Techniques in a Nutshell »