Agile Project Planning: Does Your Software Need to Go On a Diet?

Have you ever found yourself with a large feature that seems difficult to break up and still have business value?

Do you have features with estimates that are longer than the size of your iteration? Read on.

Large features that don't fit within a development iteration can cause problems in an Agile project. You want to break them up, but have struggled to find a useful way to do it without crippling the functionality.

Below are some suggestions for putting your extra large user stories on a diet.

Defer error cases to a later iteration.

Handling validation, exceptional cases, and error conditions can constitute a large portion of some features. Consider implementing just
the positive path as a first cut to present to the customer, splitting out the error handling as a separate story.

Separate user interface work from processing

Sometimes a feature has both a heavy user interface portion as well as a substantial back end. It may be possible to implement just the back end business logic, which could
then be tested with scripts or from canned data. For example, a report generator might need a configuration user interface ultimately, but you could demonstrate the report output
from sample data to begin with.

Try adding a manual step before automating

Some features are difficult because they seem to need to full automation. Adding a simple manual step can sometimes greatly simplify the implementation. Again, work with your customer to see what is possible.

Build a specific case before generalizing

Often you might anticipate a set of features needing the same type of functionality, so you design a generalized implementation that
will support future features. While a little foresight can be helpful, you may discover that building a specific implementation of a feature
is both easier and more informative than generalizing. You might actually uncover a better design.

Software is hard enough to build on time and under budget without letting extra bloat creep into both the requirements and the design.

If you can work closely with your customer to cut the fat in feature requests, you'll both be much better shape.

For more on agile tools and techniques: http://www.extremeplanner.com
(Tags: agile, project management)

Get your copy of the new book! Agile Thinking: Leading Successful Software Project and Teams

2 Comments:

It all makes sense, but I would like to assert that many error cases (and validations) should be inherent to your design.

Implementing a story with no error handling might inflict major rewrite later -- a rewrite which could be avoided since it is known in advance.

Lidor

By Lidor Wyssocky, at 2:03 AM
Lidor,

While error handling is important, it is often the case that as engineers, we can overanalyze the level of handling required.

Certainly your design can and should incorporate error handling at the low-level (managing exceptions, etc.), but at some point these need to be made visible to the customer and prioritized explicitly.

For example, a developer might decide that a simple Guest Book application needs to be able to handle database failures.

It would not be appropriate to just implement an expensive database replication and software failover system without first discussing this with the customer who is paying for it.

Even if the customer agrees that he wants a high degree of fault tolerance, you might also consider other ways of achieving it (like copying the guest book pages to another server instead of doing database replication, etc.).

When we can combine technical excellence with business-minded prioritization, everyone is happier.

By David Churchville, at 8:14 AM