Testing in one week sprints, hierarchy backlog items and test coverage.

One week sprints are great and bring big benefits to you team and product.

The artifacts that are in your system will be; image the backlog with nice small backlog. That small that they can be realized in the one week sprint. your sprint will contain a image test plan for the sprint, with related product backlog items. Probably there also will be some image additional test plans for other concerns/ risks. The image regression test plan finally will contain a collection of test cases gathered from the sprint test plans and the additional test plans. And the customer will use a image acceptance test plan for there work.



This works great. And, because the PBI’s image with their corresponding test cases image are that small the team will have the continuous discussion if the needed validation should be implemented with unit test technology/ automated test or, if it would be easier/ faster/ better/ higher ROI to specify and execute the test as a manual test. Work around testing in this way makes it a real team effort which makes it easier to get testing done in the sprint.

How should we test this PBI?

The test cases during a sprint are that small that also the image regression set will become a collection of very small validations of the system. After several ‘one week’ sprints the bigger scenario / end to end test cases are missing. A collection of small validations made the team uncomfortable about the quality of the regression and unit test case set.

For example: when making several settings the system behaves in a different way. In our situation is was the backend connection with either SharePoint 2007, 2010, 2013 or O365. Making this setting and saving this setting was one PBI. The different behavior according to this setting where other multiple PBI’s. And the overall collection of settings (all different PBI’s) made the system behaves different. We needed an Activity Diagram to explain its behavior.


The decision to make use of Parent PBI’s is easy made (we called them Features and prefixed them with this name).


Related to these ‘feature’ PBI’s a feature test plan can be created, which will cover the full scenario and all path coverage's. in this way giving the team the comfort that all paths and scenarios are covered.



Finally ending up with a bit more complex organization, but with a better test coverage.

image Feature PBI’s broken down in child PBI’s, which are partly implemented in a sprint. A nice additional benefit is that the team focuses on Feature PBI after Feature PBI, implementing them one after another. image Activity diagrams support the scenario, and when needed use case or other UML diagrams. The overall scenario (activity diagram) is related to the Feature PBI and the different actions can be related to the child PBI’s. image Testers can use their Test Design Techniques when analyzing the UML diagram for test coverage and test cases. And the image regression set will be a mix of Sprint Test plan test cases and Feature Test plan test case.




Everything perfect. But the bit more complex organization of the backlog has its challenges. Not all PBI’s relate to a Feature PBI and often a PBI’s influences / relates to multiple Feature PBI’s. The one activity diagram per feature is fake and a theoretically example, the real world is more challenging. See also Martin’s post You can’t stack rank hierarchical work items?.

Although it will give you some extra backlog grooming activities, still Features PBI’s can bring benefit to the system. Don’t try to make it too perfect and definitely have testing knowledge in place for the coverage then it is a good thing to give it a your bigger systems.


Add comment