This week is my first week with the team I’m going to be working with for the next few months. I started on the last day of sprint 28, which was also my predecessor’s last day. This week we setup sprint 29 and I broke the golden rule of not changing anything in the first sprint.
Calculating Sprint Capacity
I took a look at the historical data for the team’s velocity. The average had more than halved in the last four sprints, and sprint 28 had delivered 0 points of value. I took their average as of sprint 27 (34 points) and did some truly awful maths that I am in no way advocating. However, sometimes we have to remember that predictions are just estimates and we have to do the best with the data that we have. We lost one day of the two weeks allocated to the sprint, we had some planned absence, and many meetings. Here’s how I calculated the amount of points they should initially take into sprint 29.
3.4 points per day (34 points average / 10 sprint days)
0.5 points per person per day (3.4 points per day / 6 technical team members = 0.566)
6 days in sprint (8.5 days remaining – 1 day for meetings – 1.5 days for team swapping)
33 man days (One technical team member off for one week, so calculated man days per week ((5 technical * 3 days) + (6 technical * 3 days)))
17 points capacity for sprint 29 (33 * 0.5)
Seventeen points didn’t sound like much, but it was a good starting point for the sprint. I would rather see a team deliver more points than predicted than fewer. The delivery of work during a sprint is how a team becomes predictable and therefore builds trust with their customer. In Scrum, the work that is brought into a sprint should be completed in the sprint. The PO should be able to provide assurance to stakeholders that once work is brought into a sprint that it will be delivered by the end. If a team brings in too much work, they cannot say with confidence which will and won’t be delivered. Don’t let anyone tell you that this concept is theoretical or old-fashioned, it is at the heart of having an iteration.
Making Sense of the Board
When we went to the radiation board to start planning I found that it wasn’t empty. I couldn’t tell what was a story, what was a non-sprint task, and what was to do with the release. I understand that during a transition to agile a team won’t be doing everything to a high standard and I was thrilled to see that they were putting as much as possible on their board, but if I couldn’t tell what was going on I doubted that anyone else could. During the first sprint I’m with a team I try not to change anything so that I can evaluate where they currently are. I wanted to tidy up this board so that it was useful whilst making the minimal impact.
By looking through the tickets I found three broad categories of work being described. First, tickets in sprint that were to be delivered by the end of the iteration. Second, tickets that were for reoccurring tasks that the team does each sprint. Third, tickets that tracked the progress of a release. I added a fourth swim lane for tickets to be expedited through the system.
The next challenge was what to do with the tickets that had made it to done in the previous sprint, but hadn’t been released yet. For these, I created an area at the bottom of the board with two sections; waiting for release and released.
We’re now half way through the sprint. We’ve completed one of the tickets that remained from sprint 28, and we’ve brought in a couple of defects to do with the same area of the code base. The other remaining ticket has progressed well through development and should start making progress across the board on Monday. Any concerns that I had earlier in the week about how little we had in sprint were well founded. We will need to bring extra work in next week, but that means that the team will be over delivering and that can only be a good thing.