INVEST Guidelines – Small Criteria

In this fifth article, it is analyzed the meaning of S from INVEST mnemonic: Small. High quality user stories are small or sized appropriately. Stories represented up to few days of work (or few story points depending how the estimations is done) and fits in a sprint are considered small. Also, ideally, should be implemented by a single person in the team. If more than one person is required then perhaps it should have been split from the beginning. Opposite to this we can have two cases:

· A user-story that actually contains more than one feature to implement. If a lot of information is provided then this is an indication that the user-story has to be split. The estimation will be too big, not fitting a sprint.

· A user-story very fuzzy described, not clear details, no acceptance criteria. This is a sign that is not clear what the user expects, so no estimations can be done here. Usually, these stories at the end hide more than one features, are rather and will become as described previously.

These types of user stories, that are too big and contains several features, are considered EPICs and they should be split into several user stories that are small enough to understand and estimate. The team will provide more accurate estimates for smaller user stories. 

Splitting user stories is a deferred activity. Stories at the bottom of the backlog are going to be very large and fuzzy, with very little detail. As long as they are not highly important to the customer (with great value), makes no sense to invest effort in clarifying them. Might be the case that at the end some of them will never be implemented. It time, as implementation is progressing, the whole project could change, the customer focus could change, and these could change. So, it's okay for them to be fuzzy and large. 

As items at the top of the product backlog will be implemented, as being high priority items, these will move up and they need to be split into large user stories, they're not small enough to really do an estimate for yet, but they're much easier to understand and discuss to see how to split them up even further. 

For example, there is a requirement from the customer that the system offers some reporting. This is at the beginning. Reporting is a very large topic, so, without further discussions, is very fuzzy. Normally it goes to the end of the product backlog. Once other higher priority features are implemented, the discussion about reporting will begin. Then, the customer indicates what reports he wants to be provided by the application, in what format, if the reports are predefined or an interface should allow the user to dynamically define it, etc. At this point, the initial user-story (which was more like an EPIC) is split in several other user stories. But still quite big some of them (for example the feature to implement a user interface for dynamic report generation is not a small feature).

Once they get to the top of the product backlog, this is where they have to be sized appropriately, split further if need it, because these are about ready to be worked, to be pulled into a sprint to be worked. 

They need to be discussed, details added, acceptance criteria have to be good, and they need to have a good estimate assigned to them.