2024 Public Training Schedule
November 18 – 21, 2024 – Agile Analysis and Design Patterns
Half-Day Sessions
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
- March 15, 2023
- Integrate Continuously
This is going to be a short post.
In agile software development, small is a big thing! When we talk about small in agile, we are talking about really small. The smaller, the better. When we break down big tasks into small ones, much of the difficulty around implementing them goes away. Small tasks give us more opportunities for feedback and to check in when we solve smaller problems and generally are more straightforward to work with.
Generally, we think about a feature in terms of the story. A story contains who it’s for, what they want, and why they want it. A story is a placeholder for a feature. Features may be too large to work on within one iteration or sprint, so we break features into tasks.
The syntax for describing stories is “As a <blank>, I want to <blank>, so that <blank>,” and the typical way of describing a task, which is a component of a story, is using the “Given, When, Then” syntax. This says that given a set of preconditions, when a trigger occurs, then some post conditions will occur, which we can validate.
I like this syntax for tasks because it maps very nicely into a unit test. Unit tests have a setup corresponding to the preconditions and assertion, which typically invokes the trigger and verifies the post conditions.
I like to build the smallest product increment that still adds value to a user. Only about 20% of a feature can be valuable, and the rest may be of much lesser value, so I like to build that 20% first. My customers often don’t even want the other 80% and are willing to move on to the next feature.
How small should we build? Build the smallest thing that still provides some value. Make that value your acceptance criteria and write your test around that. That’s my best advice.
Previous Post: « Work Through Unknowns
Next Post: Validate Often »