A large number of companies out there now say that they ‘do scrum’.  This can be a bone of contention, especially for those who have a very strict interpretation of what scrum is, and what it isn’t.  It also presents the problem of taking on the role of scrum master with a team that has been ‘doing scrum’ for a period of time, but not necessarily successfully.  It can be hard to sell a new style of managing software development that comes with the same label on the tin as what’s been done before.  People who have had a negative experience of scrum may be extremely resistent to continuing to use it, even in a different form.

It’s a daunting task to take responsibility for a team. When you’re inheriting a development process that has a list of ‘issues’ so long you can’t see the end of it, it’s easy to get lost just trying to figure out where to start. In the mean time, you have a team that needs to be kept productively busy while you find a way to start progressing in the direction you want to go.  Really, the only place to start with is the Product Backlog.  If that’s not right, everything is going to fall apart.  This is something to tackle first with the Product Owner, and then with the team.

The scrum master and product owner must commit to working on the backlog and producing something useful for the team.  It can be a good idea to put this as a task in the current Sprint – even as one with 0 Story Points.  If the team is to commit to delivering what it promises, the Product Owner and Scrum Master must lead by example and do the same.  Inevitably, the team will need to get involved at a certain point to assist with breaking down the backlog items and assigning story point estimates, but there needs to be something there to start with.

To start generating the Product Backlog, a number of meetings were needed with the Product Owner.  We needed a clear understanding of what projects were potentially in the pipeline, what the deadlines were, and how to prioritise these things.  We started with an extremely high level list of about 10 items that was loosely prioritised.  For each of the items a document was created with a broad description of the item and what it involved.  I then split some of these stories into smaller ones and added some of the tasks that might be needed to complete them.  We reviewed what we had at that point and were happy that the list could be broken down into a Product Backlog that would at least cover a couple of months for the development team.  The team could now provide some input and take the first steps into being less dependent on having the Product Owner present for every single meeting.  This had been a must when requirements were only generated in the Planning meetings at the start of every week.

There are two types of roles defined in Scrum.  Pigs are committed to the project – they are members of the Scrum Team.  Within a Scrum Team you have the Scrum Master who ensures that the process is being followed and performs administrative functions.  The Product Owner represents the project stakeholders.  And the remainder of the team is a cross-functional group of people that are needed to work on the project.  Any other roles are chicken roles.  These people are not part of the process and are not committed to delivering the product, but they provide input.  Chicken roles include stakeholders (customers and vendors), end users, and managers.

Each time-boxed iteration is known as a Sprint.  This is usually 1-4 weeks long.  The less confident a team is, the shorter the iterations should be.  At the end of each sprint the team is expected to deliver a potentially shippable piece of software.  The team takes sets of requirements for each sprint from the top of a prioritised list of requirements called the Product Backlog that is maintained by the Product Owner.

To start using the scrum process you first need to define a Product Vision describing the goal of the project.  You then need to generate a Product Backlog to start working from and assign complexity estimates for each item (this may require a Team Estimation Meeting).  There are a number of meetings that are held during each sprint.  In the Sprint Planning Meeting the team discusses requirements in the product backlog, getting as much information as they need from the Product Owner.  The team then selects the requirements (called stories) they think they can commit to delivering at the end of the iteration.  The team breaks down each story into tasks and begins to assign them.  The stories and tasks for the Sprint are put into a Sprint Backlog.

Every day of the Sprint the team has a Daily Scrum Meeting to synch up, update the Sprint Backlog and make sure everyone knows how the work is progressing.  On the last day of the sprint a Sprint Review Meeting is held to demonstrate only completed stories to the Product Owner who will give feedback.  Directly after the Review meeting the team holds a Sprint Retrospective to discuss how the process can be improved.  The Sprint has now ended.  The Product Owner should make sure that the Product Backlog has been updated and reprioritised before a new sprint begins.  A Team Estimation Meeting may be required to do this.

Scrum builds cross-functional, self-organised teams that communicate as much as possible.  Teams are small with 4-9 members.  It allows for clients to make changes to the requirements and reprioritise them – but only between sprints.  The work selected for each sprint is frozen and can only be changed by the team in consultation with the Product Owner.  Visibility is high throughout the process and there are no penalties for identifying a problem. To successfully implement Scrum within an organisation, both management and team members need to buy into the idea.  It’s also vitally important to find a Scrum Master that will do a good job in coaching the team to reach their full potential.  This is a difficult job to do, as often the person who enforces change is not popular.  Someone who is a poor team lead, is not going to be a good Scrum Master.

When working well, the Scrum process is a nice one to use.  It keeps all the team members heavily involved in the project’s success and engaged in constantly making improvements.  However it can also be a difficult process to bring into a company as it doesn’t solve problems that already exist in a company – it only helps identify the issues.  Ultimately it’s up to the team to find a way to resolve any issues rather than changing the process to accommodate them.  So if input into the scrum is poor (bad requirements, individuals unwilling to work as a team), then the output will also be poor.

“I estimate that 75% of those organizations using Scrum will not succeed in getting the benefits that they hope for from it.”  Ken Schwaber

That’s the theory behind scrum. In practise, it’s not quite as easy as it may sound. Over the next few months I’ll be trying out some more practical approaches to bringing scrum into an organisation.  It seems that every organisation has its own unique approach to using scrum – what works well for one team doesn’t necessarily translate to another.  It’s interesting to see how other teams tackle particular problems and evaluate whether some of those tactics can be employed or altered to work well within your own team.

The Product Owner updates the Release Plan at the end of each Sprint to include current velocity, changes in capacity or capability, and changes in the Product Backlog.  The data can also be shown as a Release Burndown Chart plotting the effort left in the Product Backlog vs time.

The Release Plan should show:

Sprint numbers
Start and End Dates
Velocity (guess)
Comments

The purpose of the meeting is to improve the process – the issues should be addressed, rather than blaming team members.  The outcome of the meeting should be actionable improvements that are added to the next Sprint Backlog.  The team should focus on a couple of improvements that are achievable in the next Sprint.  They have to be recorded in the Sprint Backlog as improving the process is part of each Sprint Goal and progress must be measured.

The Product Owner gives feedback to the team for each task.  This includes whether the working features satisfy the requirements that were given and any feedback that should be taken into account for future requirements.  The Product Owner can also comment on whether the team has achieved an optimal velocity.  At the end of the meeting the scrum master confirms the date for the next Sprint Planning session and the next Sprint Review.

The purpose of the meeting is so that the Product Owner can inspect the work done and accept or reject it.  This makes everyone clear on what has been achieved in the Sprint and allows all team members to adapt according to the feedback for the next Sprint.  The resulting team velocity for the Sprint that has just ended is added to the Sprint Backlog report which is available for everyone to refer back to eg. on a wiki.

The format of the meeting is for each team member to state what work they’ve done since the last meeting, what work they plan on doing before the next meeting, and what impediments they have.  This allows the team to synch up and be aware of the work that is doing done as a whole.  The updates provided by each team member don’t include technical details or dependencies.  If there is something technical that needs to be discussed, any interested parties should stay back if necessary.  If a team member has completed a task, then this is the time to select a new task to work on.

At the end of the meeting the Sprint Backlog and burn down chart have been updated.  This makes progress highly visible and public.  It focuses the team on what work is left to do so it is easier to monitor whether the sprint goals will be met.  The Scrum Master keeps note of any impediments and works to resolve them.

The general rules for the standup meeting are that it should take place in the same location and at the same time every day.  The meeting must start on time and some teams apply penalties for being late.  The meeting is time-boxed to 15 mins and everyone should stand to encourage people to keep things brief.  Anyone can attend, but only the team members may speak unless invited to.  The team members answer three questions -
What have you done since yesterday?
What are you planning to do by the end of today?
Do you have any problems preventing you from accomplishing your goal?

In a situation where the team has trouble meeting their committments each Sprint, it can be useful to add a 4th question – “How confident are you that the team will achieve the Sprint goals?”  This encourages the team to speak up if anyone is worried that work is not progressing at a sufficient pace, or there’s an unforeseen impediment.  The team should always be aware that they are being judged as a team, not individuals, so the team a whole fails if committments are not met.  They must work together to succeed.

The team identifies their capacity based on the number of people available, less holidays etc for the sprint.  The wrong workload will cause the team to burnout.  About 60% utilisation is normal.  Starting with a gross capacity of hours, about 10% should be allocated for the scrum process (which will reduce over time).  Keeping the product and sprint backlogs up to date can take another 10%.  Maintenance of existing code should be allocated some time.  Finally a buffer should be applied that will be reduced over time as the team starts to estimate more accurately.

The team picks the top priority stories from the Project Backlog that it (without influence from the Product Owner) believes can be completed in the sprint, and drafts a Sprint Backlog to work from.  The teams asks questions of the Product Owner for each story – possibly agreeing acceptance tests/test data or UI designs as part of this so that everyone is clear what the criteria are for the story to be accepted as completed.  The team then discusses and breaks each requirement down into tasks and volunteers or assigns the tasks.  Tasks should be a maximum of 1-2 net days work.  This is to make progress clearer on a daily basis.  The team stops committing to tasks if the availabilty is consumed, or the knowledge/skill set of the team members is insufficient.

If uncertainty is high, dependent tasks in one sprint should be avoided.  Task estimates should not be padded – the buffer takes care of this.  The team is going to be measured by meeting their committments, not the time taken so it’s important to improve estimates as you go along.

Tasks should ideally be 4-16 hours of work.  You want to be able to tell in daily meetings if deadlines are likely to slip.  Instead of someone saying they are 50% through a 3 day task, it’s more accurate if they can say a task is fully complete or not.  The team either signs up for tasks or assigns the tasks as a group, taking into account the task priority and the makeup of the team.

Requirement     Task   Owner   Status       Work left (hours)

R1049               T028    JM        Open          12        6          8

Each day the hours remaining is updated so everyone can see how the Sprint is progressing.  This is then used to update the Sprint burndown chart each day.

In a scrum project there’s a Release Plan for the project, a Product Backlog and a Sprint Backlog.  Progress is tracked at each level.  The Release Plan is very high level and estimates are based on the team velocity.  The Product Backlog begins with coarse-grained high level estimates and progresses towards Story Points for the higher priority items.  Eventually those items will be split into tasks with ideal hours in the Sprint Backlog.

A backlog with more than 150 items starts to become unmanageable, so you can split the backlog into different levels with different estimation units.  T-shirt sizing for epics/themes and Story Points for stories.  Each story maps back to an epic/theme.  T-shirt sizing can be used to initially assign a complexity estimate.  Each item is given a t-shirt size of Small, Medium, Large or ‘Too Large to estimate’.  This helps to sort them and identify which ones need more research before estimation.

At the next level, the items can be assigned Story Points.  A Story Point is a measure of size/effort/complexity.  It’s a relative measure.  Story Points are used for long term planning and work well with big numbers… the individual estimates average out to give overall accurate estimates.  Many teams use the Fibonacci sequence (0, 1, 2, 3, 5, 8, 13).  This helps to avoid estimates being too precise and generates better discussions.  Anything higher than 13 is essentially 100 SP and needs to be broken down or reasearched more.

A common method for assigning story points is Planning Poker.  This is a well-known estimation method that highlights when more discussion is required to define a piece of work.  Each team member has a set of cards with the different story points.  After a story has been discussed, each person chooses a card.  The team reveals their cards at the same time, promoting honesty as each team member is estimating without being influenced by the group.  The people who gave the highest and the lowest SP explain their reasoning and the team re-estimates on the basis of that discussion.  If 3 rounds take place without consensus then more research is required, or the majority can be used.

Story Points are used for this estmation as it is a relative measure that can’t be misinterpreted.  Using units involving days or hours encourages others to assume an accuracy that may not be there.  People tend to be overconfident when estimating, so it’s better not to apply averaging but to use a range that you can be reasonably confident in.  The Story Points will be used to help the team judge how much work can be done in a Sprint and let the Product Owner estimate whether deadlines will be reached.

The priority is set by the Product Owner and should take into account the risks or advantages of leaving the requirement to later.  Usually high risk items will be addressed first.  It’s important to know what decisions you can defer and what ones should be done now.  A factor in deciding this is how difficult it would be to change a decision later.  Good design should keep your options open so you can respond quickly to changes rather than predicting the future.

Each requirement or user story needs to be defined well enough that a complexity estimate can be put on it.  The Product Backlog items are business requirements only, not the tasks required to achieve them.  The items at the top of the list tend to get more defined as time goes on.  It must be updated/groomed regularly.  The Product Owner will often request an Estimation Meeting with the team so that items can be discussed, updated and broken down into small enough stories that can be estimated by the team.  Items will be further defined at the planning meeting to identify tasks necessary to complete them.