First Sprint

Today we finished the first sprint of our first official Scrum project. This project is unusual because I am using Scrum to manage a transition from one internal service provider to another. As a result, we are dealing with a list of internal system and website changes that is fixed in scope. In other words, all user stories are non-negotiable and all must be done by a contractually set date.

Even though this project sounds like it goes against every Scrum principle, we are still finding tremendous value in following it. At the User Story Writing Workshop, just by sitting down the Product Owner with our team, we've identified new items that haven't been considered before, while at the same time, after a thorough discussion some tasks ended up being dropped. The workshop was a very intense four hour run, but everyone left the room with a much better understanding of the overall scope. I think for the first time in weeks, people could see the entire project all the way through and had enough confidence that nothing major has been left out of planning.

We've dropped the ball with the first sprint, though. A lot of it can be attributed to the chaos of San Diego fires. Out of 28 story points assigned to the sprint we finished... none. Still we had decided to push through with the demo and sort of fumbled through it by taking the audience through the project, explaining what Scrum was, etc. I realize that this can only work once. Fine.

The demo had an interesting side effect. Scrum is used to manage the IT part of the project, but there is a whole lot of coordination happening on the business side among various departments: sales, marketing, compliance, etc. Usually, on projects of this nature all communications among departments are ad hoc and person to person. But suddenly, the demo became a focal point for all department reps who were at the meeting. As soon as the demo was over they started talking to each other, sharing their statuses, turning the meeting into a de facto Scrum of Scrums. We noted this in the retrospective and decided to keep the practice going.

After the demo we held a productive retrospective meeting and tried to explain our failure to deliver. I also took that time to talk to everyone about minor Scrum related transgressions that were made here and there (like talking at the demo about personal commitments vs. team commitments, or a developer taking a change request from a customer and starting to work on it in the middle of a sprint without notifying anyone on the team... primarily me). After that we dove right into planning the second sprint.

For the first time, thanks to the recent scrum training, I had a very good idea where I was going with planning. Since there is no reliable velocity history, we started with the remaining highest priority story and proceeded breaking it down into tasks. I insisted, though, that if possible every task be under 8 hours. Agreeing on tasks for the first story took a long time. However, the entire process was very helpful to our QA specialist, allowing her to dig into low level details on what and how to test. At the end I asked everyone to commit to the hours written down on task stickies and once I had everyone's commitment, we moved on to the second user story.

Again, we broke it down into tasks, but when time came to commit, the developer who had to do the majority of work on the first two stories said that seeing the total time now, she wasn't comfortable committing. I offered to split the story into two: one for this iteration, one for the next. We found a really nice seam along which to split the work and after moving tasks around and recalculating the hours, everyone happily committed to the second user story.

Upon finishing the third user story, we've hit a bottleneck: one developer and the tester were tightly booked, while the other developer could still take on more hours. The decision was not to commit to any other user stories since there were no resources left to test them, but have more stories handy in case the second developer runs out of work.

All-in-all, this was a very productive meeting. I got an impression that everyone finally understood what was required of them and how Scrum could help them to be efficient. In two weeks I will have direct evidence whether it actually worked..