Test Driven Sprint Planning – Retrospect

A while ago I blogged about trying out a different method for sprint planning.

The sprint went well, but unfortunately I had to leave that team so I couldn’t continue my experiment for longer than one sprint. I gathered some feedback from the team members to get some idea about whether the experiment was in any way good and if it’s worth to continue it at some point.

Here are the results:


The method of planning tasks as tests-based during sprint planning session:
  • Most team members thought that it wasn’t more complex than usual way of planning
  • One team member thought that it was simpler than the usual way of planning
Benefits for the sprint planning part:
  • Most team members thought it provokes thinking about how specific tasks will be tested
  • One team member thought it makes it easier to find all tasks related to a certain story
  • One team member thought that the tasks also work as acceptance criteria
Sprint execution:
  • Half of the team members had to add more tasks during the sprint, because:
    • wanted to make sure that some minor feature details were working ok
    • the tasks in a story were too little to cover it
Task granularity:
  • Most team members thought the task granularity was good
  • One team member thought the tasks were too big to be able to use them as unit-tests but too small for the story to get fulfilled. This team member wasn’t present in the planning.
Tasks as basis for the  list of unit-tests:
  • Most team members used the tasks as basis for their list of unit-tests
  • One team member couldn’t use the tasks as basis for the list of unit tests. This person wasn’t present in the planning.

So, what did we learn from this experiment? To me this looks promising, there was no single person in the team who thought this was rubbish and shouldn’t be tried again. On the other hand, there were few team members who weren’t part of the planning session and the method wasn’t explained to them in more detail. As a result one team member thought we were trying ATDD, which wasn’t the case. Several people said one sprint is too short time to make any good conclusions and I fully agree.

Regardless of this, I have heard the team still does the sprint planning using traditional methods.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s