Tags

, ,

Test Driven Development (TDD) is broken (or at least is implemented very badly by most organizations) see our previous post for a great explanation about why it doesn’t work. What TDD needs to become is business oriented testing that can be used as the “definition of done” as described in scrum.

Our approach is similar to the approach taken in the Sprint Planning Meeting where the Product Owner and the team negotiate which stories a team will tackle during that sprint. The difference is that we believe that rather than just doing an estimation of effort – the first task is to use business value as the main vector in estimating what should be achieved during a sprint. Together the product owners and developers create a chart for each proposed user story.  In that chart the product owner uses the y-axis to indicate the business value and the developers use the x-axis to indicate the associated effort. Then stories are classified into one of four categories as shown in the figure below – Oyster, Pearl, Quick Win and White Elephant.

ease value matrix

The idea is find the mix of stories that maximize business value subject the time\resource constraints. The methodology is to first focus on Pearls and trash the White Elephants  – don’t do them just because they are there. Oysters are usually too difficult to complete in a single sprint and should be subdivided into user stories that can be implemented in a single sprint – i.e. Pearls, Quick Wins or White Elephants. Finally use whatever time\resources you have left for Quick Wins – do as many as possible.

An example is the failed Apple Navigator project. Apple tried to incorporate a cool new story – navigation enhanced by real-time 3D imagery. This story turned out to be the oyster that ruined the project. What Apple should have done is decompose the oyster into its components: navigation and imagery. From a business perspective navigation is a pearl, while imagery is a white elephant.

Once the stories are selected – developers should work on implementation and testers should start working on the business acceptance tests – the tests that define the required business results from the sprint. These should be generated from the sprint’s user stories.

These business acceptance tests are the ones that matter and should live as long as the user story (as regression tests). They are independent of implementation – and therefor also independent of refactoring or other changes to the system.

Advertisements