Many times when picking Features as execution unit, it’s hard to fit a big Feature into Sprint. This always cause the feeling of Features is too big as an execution units, leading some organization to prefer User Stories over Features, wrongfully neglecting Features over time. User Stories as execution unit are not the optimal way to go as they don’t provide enough value by themselves – you need to have “enough” Story Points to release a valuable version to your customers. They are also too abstract to understand the big picture, missing the overall why behind them. I believe that Feature broken into Tasks is a better approach and better execution unit. Obviously, there are multiple approaches to deal with big Features. You should pick the right tool according to requirements and people involved.
Breaking Big Feature, some options:
1. Extract design from execution: You can complete the design of a big Feature in Sprint 1 and implement it on Sprint 2. This way, instead of having a very big design effort and implementation effort on the same Sprint, you can use the first Sprint to understand effort and risks and use the second sprint to implement and deliver the goods, after understanding ROI better.
2. Extract framework from client: User Stories, just like Scrum in a way, introduce too many “Do’s and Don’ts”. For example, it’s considered a “bad practice” to have Technical User Stories. I believe that if the framework has specific needs (raised by the Feature) and it’s easy to break it out from the Feature itself (user behavior), it’s perfectly okay. It’s actually another step in the right way to build confidence as part of your Sprint!
3. Break big value to multiple smaller values (*caution*): Features, by nature, bring a value to your customers. It is possible though, to break the value into multiple Features, each carries only part of the value, without damaging the overall behavior. Instead of creating a “Search Engine” feature, it’s perfectly fine to define “People Search” and “Articles Search” as different features, each bringing different value. It’s even better to define sub Features inside “People Search” to enrich user experience over time, according to feedback by your customers. Caution: you need to do it carefully, sometimes breaking a Feature into multiple Features is silly as each doesn’t bring enough value by itself, until all of the pieces come together. Still, this is a powerful question to use: “Can we deliver real value to our customers by breaking this into multiple parts?”.
Most of the time, your Features should be small enough to fit a Sprint. It’s that simple – if the features are usually estimated in 2 weeks, don’t have a 1 week sprint. That being said, you should have the right (or at least some) tools to handle big Features. If it wasn’t obvious so far, don’t be afraid to “twist and mix Agile”. You owe it to yourself to understand why you’re doing things and adjust it if needed, even if it’s written in some book that it’s a “bad practice”. It might be bad for them, but it might be perfectly fine for you.
I remember enjoying Jeff Atwood’s (aka Coding Horror) post about “code isn’t beautiful”. It took me a while explaining to myself why people are chasing after “beautiful code” so much. Why people are so passionate finding or forming beautiful code? Should great painters talk about beautiful colors or beautiful paintbrushes? I always thought they appreciate the entire painting, created and driven from emotions, dreams, ideas, styles and yes – colors & paintbrushes. They appreciate “the all” more then the exact technicalities. Why are we trying to figure out the best paintbrush to use or the best color? Why not trying to figure out the “best all”, the best experience, the best value, the best process?
I would define Beautiful Software as a surface to allow three magic abilities to emerge:
- It should be easy to add new Features.
- It should be easy to change existing Features.
- It should be easy for new teammate to become productive almost immediately.
If you’re able to have these abilities in your painting, your software, then you’re probably doing something beautiful; you probably figured out the correct paintbrushes, the right colors and most important – how to use them wisely to introduce true beauty.
I am not mentioning pseudo-code, language specific or whether or not testing is worthy. There are many ways to paint beautifully, it is up to you to figure out what makes software beautiful to you and figure out the right tools and process to achieve it. Don’t hang to tight to the “perfect algorithm” or “perfect Design Pattern”. There is nothing neither perfect nor beautiful about color or paintbrush by itself.
Once you decide how to break a feature into tasks, it’s crucial to make sure you don’t leave any leftovers as part of the breakdown. Feature breakdown must include each and every task to make it a complete unit you can deploy as part of a version. Completeness means that not only a Feature is deployable and it can be monitored, it’s also with great external quality (no major bugs left behind) and great internal quality (design-review, QA test-cases review, code-review, UI review).
You want to price a Feature by the gross organization time; this is the only way to understand how much a Feature really costs. Knowing that, you can correctly price future roadmap without needing “Bugs Elimination Sprint” or “Big Refactoring Sprint” to introduce quality after things were delivered to your customers.
1. Design review – may it be over emails or formal meeting, the design should be solid and well thought
2. QA test-cases review – making sure QA will test the right things or add more test cases for relevant edge-cases.
3. Testing time – writing tests (unit + integration) should be priced as part of the Feature, not after, not next sprint.
4. Code review – for knowledge sharing and internal quality validation.
5. UI review – making sure the UI look & feel just like Product team wanted it to be.
6. Bug fixing + validation buffer – fixing major bugs should be priced as well! if you’re not sure how much time to spend, start with 5-10% of the total estimated effort, and learn from your experience (by Feature size, complexity etc)
You can add more to this list, if the team/organization needs it. The idea is to make sure that once a Feature is complete, you’re feeling great about it and got confidence it won’t be fired back to the kitchen, to cook from scratch. You should have the same confidence about changing an existing feature; it should be easy, voodoo-less and highly testable to do so, with low chances of breaking other flows in the system.