SCRUM With Overtime
With the change to Agile working and the creation of Scrum Teams in my organisation, I can see people drawing breath with the mention of overtime.
My project is being run under SCRUM and is actually going okay. However, unlike a true SCRUM project we have a fixed and immovable end date. The project has been thoroughly planned, pointed and the backlog refined with an MVP identified. We have enough skilled resources in the team to complete the MVP at a pinch by the end date.
However we are cutting it very very fine.
The problem I have is contingency. If something goes wrong, or there is a significant defect or rework required or there are unplanned absences over and above any contingency we have built in to our sprints.
I understand the steps normally taken with a SCRUM approach, further refinement of the backlog, resource amendments, speaking to the customer etc etc. But I have been offered 50 hours of evening and weekend working, such is the nature and importance of the project.
If I used this overtime to counter slippage and delay of the project or additional contingency, how do I count it against velocity? Should I make some of the hours available at the beginning of the sprint (almost like an additional team member) and record them on a Burndown chart? Alternatively, should I monitor the teams hours and velocity as normal and then at the end of the sprint calculate how many overtime hours were needed and show the team the impact if the overtime had not been available?
I feel that I should take this additional overtime as it has been made available and not look a gift horse in the mouth, but as Scrum Master I want to be able to handle it correctly, account for it and show how it impacts the team for the better or worse.
Any thoughts, experiences or ideas would be greatly appreciated.
Regards, John
Hmm,
Hi John, a couple of comments come to mind on a first reading of your post.
Firstly I would not be worried about 'accounting for the overtime' in the velocity calculation, the teams velocity is what it is and should ideally be worked out as an average of your last few sprints or worst case use the velocity of the last sprint if you've just started with SCRUM.
Secondly a non SCRUM specific point is I would worry about depending on overtime. There's a great book by Steve McConnell which talks about 'death march projects' and their inherent dangers.
If your deadline is immovable then as you highlight I agree that the scope needs to be negotiable if it looks like slipping, at least if you implement a burn down you should be able to see if things look too off track.
Regards,
Andrew
John,
A few items and questions for clarification:
1) You state that you are the Scrum Master. If so, you do not have a "project". You serve your team.
2) I am assuming that it is your team that provided the points for the backlog stories that compose the MVP and the project. Any estimates that were determined otherwise are poor at best, since they do not reflect the opinions or capacity of those doing the work.
3) Scrum can certainly work with a fixed end date. What Scrum cannot work with is a fixed scope. In fact, scope is the only project management pillar (time, cost, quality) in Scrum that isn't fixed.
4) If you are working with a fixed project scope, then it makes no sense to apply an Agile framework like Scrum to the work. Are the product backlog stories truly prioritized, or are they just a sequential representation of the project? If you cannot de-prioritize any of the project stories in the backlog in order to meet a deadline, or account for unforeseen efforts (rework, defects, etc.), then you are unfortunately not working Agile-ly.
5) Is your team producing working software after every sprint? If not, why?
6) Who offered you 50 hours per week to work on this initiative? Scrum is about maintaining a constant pace (principle #8). There is inherent waste involved (according to lean principles – Mura, Muri) whenever we adjust the workload or place greater stress on people or processes.
7) My strong suggestion is if you cannot change the current situation, then measure velocity as you always have. Velocity is based on the team’s production sprint to sprint. Don’t go down the “rabbit hole” of adjusting velocity based on the number of hours worked. Still, this information (# of hours/sprint) may be beneficial in highlighting the reason(s) for changes in velocity or quality of work.
.
> The problem I have is contingency. If
> something goes wrong, or there is a
> significant defect or rework required or there
> are unplanned absences over and above any
> contingency we have built in to our sprints.
How have you built contingency into your Sprints? What form does that contingency take? Is it scope that can be sacrificed while still allowing your Sprint Goals to be met?
In Scrum, the minimum that is needed to meet a Sprint Goal would effectively represent an MVP. It isn't a batch of work that is planned and built up over a number of Sprints and only then considered fit for release.
Defining an inflexible batch of requirements is not the same thing as having an MVP. It's fine to have an immovable end date as long as scope flexes to accommodate it, and some releasable value can be demonstrated each and every Sprint. The iterative, incremental, and demonstrable release of value is the primary control surface for managing a team's forecasts and commitments, and for accounting for time and money spent.
Hi all,
Many thanks for you comments and advice. I have plenty to consider here and I will not adjust the velocity to accommodate the overtime (if used). That did not feel right from the off.
I will keep the overtime as it is available and as an option if needed. But I understand the point made about additional stress and waste.
Unfortunately, I cannot go into too much detail about the project (point taken, it is not my project, but along with the team we all own it), or how my organisation operates. But I can confirm that the scope is not immovable only the end date is fixed. The Product Owner is co-located and is regularly reviewing each sprint and its content and priority, but with the aim of delivering an agreed MVP by the end date.
The contingency that we have applied are one lighter sprint part way through the project for completing outstanding tasks and an empty sprint before the end date to complete the truly outstanding tasks if any along with transition. If this is not required (I dream :-) ) then we will not seek to add any extras, but concentrate on training and communication plans etc for our customers.
This is the first Agile project this team has experienced and I can imagine we are making some mistakes and maybe not following all best practice, but what has been applied from Agile working so far has been largley effective and it is a significant learning experience going forward.
Thank you again for taking the time out to respond to my questions / situation.