Very frequently when you are running with scrum or another agile process you’ll get objections like ‘you can’t plan with agile methods’, ‘how can we schedule what work to do?’ and ‘how can we commit to any deadlines?’
The myth with scrum and agile methods is that it is not possible to work out when functionality will be delivered, people usually fall back to waterfall and Gantt charts and say ‘look, if we do it this way we know when the work will be completed and can tell the client’
Unfortunately most people that have spent any time working on software projects know that this is pure fiction. Having a chart that tells you when a piece of work will be delivered is a complete suspension of belief, just because the chart says it will be so doesn’t mean it will be.
So how can you schedule using scrum? by using the tools that we already have – backlogs, velocity & story pointing.
Planning
You start by ensuring you have a backlog with stories that have the correct level of detail to enable the team to perform story pointing, this will then tell you the size of the work to be done; you can then use the teams velocity to be able to work out the amount of sprints you are likely to need to be able to complete the work.
What becomes particularly important is having a range for the teams velocity e.g. maximum velocity achieved, minimum velocity achieved and average or mean velocity which equates to a what the team will be able to achieve, should be able to achieve and may be able to achieve.
Estimate vs. Commitment
One question often asked is why use story points, why not provide estimates in hours or days?
One very good reason is that story points are a unit of relative bigness, in and of themselves they have no meaning. If you say to a product owner a story is estimated to take 5 days to complete then frequently the product owner hears ‘that will take 5 days to complete’ when what the developer really meant was ‘if I am undisturbed and able to work on this and this alone and it all goes to plan I believe it will take 5 days’.
This is the trap of estimate vs. commitment where development say one thing and the business hears something entirely different, this is often the cause of friction when work is not completed when the business expects.
This is where story points help because they aren’t tied to any particular time frame, number of days or hours, so the likelihood of an estimate being taken as a commitment is reduced.
Scheduling
Scheduling the work to be done may not be a pain point, it all depends on the environment and amount of ‘resources’ you have.
If you are on a normal sized scrum team (7 people + or – 2 people) that works for a single product owner on a single project/product then once the product owner has decided what work should be in a sprint you are good to go, no issues about resource or scheduling.
However, if you are a team that has multiple product owners and works on multiple projects/products it can become a real issue trying to schedule what work will be done when especially if you have smaller teams.
Whatever happens the team should not attempt to decide which product owners work they will do, it is not up to the team to decide which work has the most business value it is up to the business.
In a perfect world you could hold a meeting that all the product owners attended and they would form a self managing team and decide which work was of most value and attempt to work out a schedule between them of when to do each product/projects work.
Unfortunately we don’t live in a perfect world and most often than not each product owner will believe that theirs is the most important work and should be done first. The easiest way to resolve this is to have an arbitrator for the business, somebody who can and will decide which work is of the most value to the business at that time and as such should have priority.
For this to work the arbitrator has to be a senior figure in the organisation, somebody that the various product owners will listen to and abide by their decision. The arbitrator chairs the product owners meeting and will hear each product owners case as to why their work is the most important and the actual or perceived value that will be gained through doing the work, the product owners will also state how many sprints that they need to complete their work based on planning done with the team.
Once everybody has stated their case the arbitrator will be able to decide what order the work should be done in, there by scheduling the work for the team for the next sprint as a minimum but quite possibly for the next
3-6 sprints.
To ensure that the business can react quickly to changes in its environment (market opportunities, competitors products, regulatory/legislation changes, etc) this prioritisation meeting should take place every 2-6 weeks allowing for the schedule of work to change but ensuring that the team isn’t disturbed in the work they are doing.
Deadlines
So we have covered how to and avoid confusion over estimates and how to schedule work (if necessary), now the business wants to be able to commit to delivery but they are still feeling nervous about whether the team will be able to deliver on time.
So how do you allay these fears? You complete the work you commit to.
The team needs to ensure that the work that is taken into the sprint is completed which means you have to be honest with yourselves about decomposing your stories into tasks, about how the work is progressing and communicate with the team (including the product owner and customer) so that if anything crops up to affect the schedule it must be raised immediately. By doing this the product owner and/or customer can make decisions as soon as possible on any stories that may need to be dropped from the sprint, changed or re-prioritised.
By doing this the business/customer is able to ensure that the stories with the most business value are completed.
Next pain point
The next pain point I’ll cover is in relation to integrating scrum into the wider business and problems that may be encountered.
No comments:
Post a Comment