Finish the sprint by starting the day with a screw up. Yes, I was late!

My alarm refused to go off and I slept in till 9.30, threw myself out the door and got to the meeting 5 minutes late, so first bad mark there. To make this even worse I didn’t realise this was being role-played and so while trying to prepare to answer a question (I wanted to sneak a look at the sprint backlog) I caused a second screwup for which I appologised to the group for. I was mortified when I realised what was actually going on, that this wasn’t a meeting with Janet the lecturer, it was a meeting with Janet and Craig the “Customer”. Whoops.

So, disaster aside we managed to re-order the product backlog for the customer in such a way that I think they were happy. One of the stories that would have made the backlog for the second sprint had most of it’s requirements already completed so we reduced the complexity based on that information. The customer replied by reducing the business value and adding a new user story.

After the changes to the backlog were complete in which we walked away happy we proceed to have an informal meeting to discuss sprint 1 and what we thought of it. We know we didn’t do amazingly well, we also know that there are things we need to improve for the next sprint.

On the flip side we all did agree that we have definitely all learned something from this sprint and we do feel that the next sprint will be easier since we have a better idea of TDD, Pair Programming and Scrum. We also know what mistakes we made and what to avoid, which is part of the whole process.

We did then move on to have our Sprint Planning Meeting for sprint 2 and we identified that the user stories will be easier this time around and we took a lot more time thinking about the tasks, breaking them down, discussing them and assigning real estimates of the times they will take. This is something that really hurt us in the first sprint and none of us wanted to make that mistake again. We totaled up the number of hours we assigned each task, broke it down in to the pairs and looked at the complexity we had assigned each story, judging by this we have got much better estimations this time round.

We may even managed to blow right through the backlog and get onto another user story, that would be a nice bonus to this. It would be in stark contrast to sprint 1 where we only got 1 out 3 stories completed.

On the whole I do feel we could have done better on the first sprint but there are a number of reasons why we didn’t and a lot of this has been to do with the learning curve involved. As stated in one of the scrum case studies, most sprints are 4 weeks long and it takes teams usually 2 or 3 sprints to actually “gel” together and work together in the best way possible. We do not have that luxury and 2 weeks per sprint really forces some hard and fast decisions to be made, especially when this is not the only project of this scale on the go.

In the end, we can only do so much and the team has really put in the effort for this, we are all ready for the second sprint and hopefully it will go much better.

And just because it was the highlight of my day today:

“Everyone on the Refactor Tractor!!!” (ask Alan, he started it!)