Wednesday, January 28, 2015

Practical Scrum Training (5) Discussion of Product Backlog (continued)

As promised in the previous post, we are going to discuss the product backlog item:
In order to secure integrity of family tree data as a family tree user, I want to have checks for all data I enter so that entering invalid data is not possible
Is this an easy one, or rather difficult and big? Maybe it's not super-difficult, but it is a large one, probably in the top three biggest items that we currently have in product backlog. How can we break it down?

First of all, let's realize which data needs to be checked. When adding a new person to the tree, we enter:
  • name and surname - these probably do not require any checks
  • mother and father IDs - definitely needs checking
Now, depending on the order of the product backlog, we may or may not have additional attributes that need checking. If we deliver an increment with birth and death dates and gender attributes available for the user before we deliver this item, then this will open a whole new set of checks and the item will be even larger. On the other hand, if we deliver this item first, then we will probably need to think of checks while doing the gender item or any other product backlog item that has to do with person attributes. Doing checks will then be an integral part of the items ordered later or it will be covered by a separate backlog item, to make product backlog items smaller. In this context, think about the product backlog item that adds the ability to edit person's data.

Let's leave the order of product backlog items aside for a while and consider the checking of the IDs of the parents. We could say: that must be a number - and just check if that's a number. This would be purely syntactical checking. But we could go further and check if an ID entered actually exists somewhere in the tree (that is, is a valid ID of a parent). We could even check if a person is ever added / editted as their own parent and disallow this situation. Or wait - we could also check that the IDs of the parents are not equal to each other, which would mean someone is trying to set the same person as mother and father. And all these possibilities are good cases to consider for checks, even assuming that we do not have gender attribute developed yet.

There is also one extra hint that I can give you: did you notice that this item contains the word all?
In order to secure integrity of family tree data as a family tree user, I want to have checks for all data I enter so that entering invalid data is not possible.

Beware of this word in any product backlog item you see. That means it is too general and it tries to embrace too many known and unknown things.

Product backlog items that use universal quantifiers (like "in all cases", "for every possible configuration", etc.) act like magnets and they attract newly identified scope, making the item difficult for the team to finish within a sprint. 

Even with the assumption that we have not developed anything prior to this product backlog item (no dates, gender, etc.), we could divide this item into several smaller ones:

In order to secure integrity of family tree data as a family tree user, I want to have checks for all data I enter so that entering invalid data is not possible.
can be refined into:
  • In order to maintain integrity of family tree data as a family tree user, I want the identifiers of the parents checked (natural numbers, identifiers are optional) and blocked from being entered if invalid
  • In order to maintain integrity of family tree data as a family tree user, I want the identifiers of the parents checked to be existing identifiers of people already existing in the tree and blocked from being entered if that is not the case
  • In order to disallow non-logical connections in the family tree as a family tree user, I want to be blocked from pointing a person as their own parent
  • In order to disallow non-logical connections in the family tree as a family tree user, I want to be blocked from pointing the same person as both mother and father of someone
Isn't that nice?

See also