ITOps Sprint 1 Review
ITOps Sprint 1 Review
Join the DZone community and get the full member experience.Join For Free
The need for DevOps innovation has never been greater. Get the results from over 100 business value assessments in this whitepaper, Digital Darwinism: Driving Digital Transformation, to see the positive impact of DevOps first hand.
- 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.
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|
- 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
Friday to Tuesday were the least productive days in terms of project work. This was mainly due to
holidays which “we” (namely me) hadn’t taken into account, with 2/3rds of the team being off at one point.
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 , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.