DevOps Zone is brought to you in partnership with:

By day I'm a build and release engineer in London, but by night I'm a normal person! If anyone ever asks me what I do, I usually generarlise and say "I'm in I.T." and then check to see if they've already stopped listening. When I'm not working or blogging I can be found playing rugby or cycling around the countryside on my bike, in an attempt to keep fit and fool myself into thinking I'm still young. James is a DZone MVB and is not an employee of DZone and has posted 54 posts at DZone. You can read more from them at their website. View Full User Profile

ITOps Sprint 1 Review

12.28.2012
| 2688 views |
  • submit to reddit
Our first ever ITOps sprint completed on Friday 7th December amid much fanfare and celebration (ok, that’s a bit of an exaggeration). The team completed a whopping grand total of 103 points. Among the highlights were:
  • An Anti-Virus upgrade
  • A new dev server
  • 10+ IT Requests from the backlog

Yes, those were the highlights. But don’t scoff – that new dev server was AMAZEBALLS.

Retrospective

The format of our first retrospective was to spend 5 minutes writing down (on cards) what we felt went well in our first sprint, and what went not-so-well. We then discussed these and made a list of “lessons learned”. It turned out a bit like this:

What went well What went not-so-well
2 week “focus” made a huge difference: we could concentrate on a smaller number of tasks, rather than work from a massive backlog with no end in sight. We under-estimated task sizes. Massively, in some cases.
Having the tasks on the board helped us see what everyone was doing 7 point task sizes were waaaaaaaaaaay too large
When working on a task, we no longer felt that we perhaps ought to be working on something else We did fewer IT requests than we would otherwise have done
Time-boxing certain IT requests was a good idea. We didn’t take holidays into account when we did our sprint planning! Duuuuuh.
Improved visibility: the rest of the world could see that we didn’t actually spend 2 weeks updating Facebook We failed to get much done on the new File Server
We got through more project work than we expected
Easy to visualise the sheer amount of unplanned interruptions
We prioritised our interruptions quite well

Lessons Learned

  • 2 week sprints work well for the team’s focus
  • We should time-box research into upcoming projects
  • Any task which is above 5 points should be broken down into smaller tasks
  • We need to improve our estimation
  • We need to focus on completing the projects if we’ve committed to them
  • We need to take holidays into account!
  • Relative to interruptions, we can do more project work than we originally expected

Facts and Figures

  • We completed 103 points
  • 53 points of which were project points
  • 50 points were interruptions
  • 15 points were in progress at the end of the sprint
  • 9 points (of committed work) remained incomplete
  • 4.5 points were blocked

The Burndown

Friday to Tuesday were the least productive days in terms of project work. This was mainly due to hangovers holidays which “we” (namely me) hadn’t taken into account, with 2/3rds of the team being off at one point.

endbd

Conclusion

Sprint 1 was an enjoyable success within the team. The increased visibility of interruptions as well as a clearer focus on our tasks was refreshing.

We failed to deliver one project (the new file server), which is disappointing, and we will need to focus on progressing and completing our project tasks in future.

We’ll continue with Scrum for the time being.

The other thing we noticed was that interruptions take up more time than just the duration of the interruption. There’s an additional amount of time on top of each interruption which needs to be taken into account. When someone is being productive working on a project task which, let’s say will take 3 hours, and they get interrupted to do an IT request which may only take 1 hour, the total time for completing the project task PLUS the interruption isn’t going to be 4 hours. It’s more likely to be 5, and this is because it takes some time to get back to being fully productive.

We made a conscious effort not to measure tasks by elapsed time, and instead we tried to use “Level of Effort”. I thought that mapping points to hours would be a bit too convenient for observers to draw incorrect conclusions by just adding up the number of hours and comparing it against the number of points we achieved! By using Level of Effort points and taking into account the number of interruptions (at the end of the sprint the points showed us that we’d done an almost equal number of interruption points as we had done project points), it was clear that in future we need to buffer our estimations somewhat. :-)

Published at DZone with permission of James Betteley, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)