Recently, I’m working on an assignment where we follow Scrum processes. It is not according the theory, but it helps us to work in two week sprints. I’m testing a big release of a new developed application in a few sprints together with some other people. We have test ideas defined, some of them are scripted. Luckily we are using the Session Based Test approach to do our test work. We write down our observations in session reports.
A real challenge was how to plan the workload in a sprint.
First a little back ground on Session Based Test reports. According the theory, a time indicator can be given for session reports. We have three types of session reports; short, normal and long
This gives the following overview
short 60 minutes +/- 15 minutes
normal 90 minutes +/- 15 minutes
long 120 minutes +/- 15 minutes
I used this as a reference and introduced a forth type of session report, i.e. double-long
The following overview can be defined
short up to 1 hour
normal between 1 and 2 hours
long between 2 and 4 hours
double-long between 4 and 8 hours
I translated this to story points
Session Story points
double long 5
With this ’translation’, we as a the team were able to give story points to the (planned) session reports.
The following rule of thumb is in place. A tester can create 3 “normal” session reports per day. This is an average based on experience of people familiar with the Session Based Test approach.
Using this rule of thumb we defined within the team to plan about 5-7 story points per day for our test activities. This means, in a sprint we plan/burn 50 to 70 points on test activities per two week sprint.
The first sprint results gave us a clear burn rate, information where our product owner and scrum master were pleased with. This process started to work for us.