The Scrum process at HR SoftCo is very similar to classic Scrum as outlined by Ken Schwaber in Agile Software Development with SCRUM. The differences are based on experience of what works best FOR US, the latest Scrum thinking and being part of a globally distributed Scrum team. We use Scrum as a wrapper process for Extreme Programming and Test-Driven Development. We are committed to quality!
This is not an introduction to Scrum. It is information about how we have implemented Scrum for our global team. For basic information about Scrum, please see http://www.scrumalliance.org.
1 Why Did We Start Scrum?
There were several factors involved here. The office I work in was once a small UK company. When HR SoftCo (a large US company) took over they were in the process of converting all of their teams to use Agile techniques. Our team already had an interest in Test-Driven Development, but had made no inroads to developing it further. We had all the usual waterfall related issues such as quality, knowledge distribution, late delivery, building the wrong software etc. With the support of HR SoftCo we were able to implement completely new processes and transform our work.
2 How Has Scrum Helped Us?
Our Scrum process allows us to:
- Develop ONLY the right software
- At the right time
- In short, low-risk increments (Sprints)
- That respond to change easily
- And make an organisation more competitive
- In a low-stress manner!
3 What Is Our Team Structure?
We have a classic small, cross-disciplinary team. The members are:
- 1 Scrum Master
- 2 QA (not enough!)
- 7 Developers
- 1 Product Owner
To make up the short fall in QA, everyone else helps out as we need to write / execute tests etc.
Outside of our team there are over a hundred other developers working in other Scrum Teams. We use a "Scrum Of Scrums" type system to manage communication between teams.
3.1 Scrum Master
The Scrum Master is now always the same person every Sprint. This is to comply with the practice of the other Scrum teams within the organisation. We used to rotate the role every Sprint which was a successful practice. In reality it does not make a large amount of difference whether we rotated the role or kept a single Scrum Master.
3.2 Product Owner
We share a Product Owner with two other teams. This means that our Product Owner’s time is very limited. The side effects of this are:
- We do not always have up to date requirement documents
- We sometimes miss him at meetings
- We have delays in getting User Stories signed off
The problem is exacerbated by other personal changes relating to Product Management. Hopefully, these changes will soon be resolved! We are managing this difficulty through a little understanding and the use of email and our colleagues in the USA who are in the same time zone as the Product Owner. They are in a better position that the UK team to chase him around the building!
4 What Documentation Do We Keep?
We have:
- Wiki
- VersionOne (soon to be Jira)
- Sprint Backlog
- Burndown
- Definition of done checklist
4.1 The Wiki
We have a Screturn Wiki (http://www.screwturn.eu/) which we use for storing information that is useful for the entire team. The Wiki is 100% open for anyone within HR SoftCo to read and edit. The key pieces of information we keep on here are:
- Team holidays
- Impediment list
- Documentation for testers
- Documentation for support / implementation
- Software release prodedures
- IT infrastructure information
- Development processes, procedures and policies
We keep team holidays on the front page of the Wiki so people in both offices can see who is in the office when. We have part-time staff as well as full time so this is important!
The impediment list is only for impediments that cannot be immediately resolved. At the time of writing there is only one item on this list. Unfortunately, it has been on there since September 2007... It relates to developing for good performance, which is still an area we are struggling with. The impediment relates to the lack of performance profiling tools available to the team.
Documentation for testers and support is written by developers. For any user story, this is rarely more than a few lines. This documentation usually relates to things testers and support would need to know such as how to configure new features or things that could go wrong and how to fix them.
It is worth noting that developers do not write user documentation. Interestingly, neither does the product owner. There is a Knowledge Management department at HR SoftCo that does this. Unfortunately they are not tied in to our Sprints and so we cannot include User documentation as part of our Definition Of Done.
Software release procedures are important. The Automation At HR SoftCo article details how we have automated this procedure. The Wiki documents how to run the automated procedure and also covers a few manual steps that should be taken.
The IT infrastructure information is useful for everyone. It details which of our servers are for what purpose (e.g. OS patch testing, Product Owner approval, User Story testing, continuous integration etc).
Finally there are a few documents relating to software development processes and procedures. There is a brief outline of Scrum, information on how to join phone conferences and Live Meetings for reviews, information on where to find requirements and completed "Definition Of Done" documents, etc.
The Wiki is hosted in the UK office. The US and UK parts of the team are on completely separate networks, and so both teams have the ability to VPN on to each others' networks to get at information. We are currently looking at how upgrading our connectivity as we are slowly increasing our transatlantic network activity...
4.2 VersionOne
We currently use VersionOne as a repository for User Stories (new features and bugs). This is hosted in the US office. The Product Owner adds User Story documents (Word docs) to Version One and assigns them a Story number and (when the Sprint begins) a Sprint number. For speed, we download them at the start of the Sprint on to the UK network. If the documents change, the Product Owner lets us know and we download them again. We don't spend a lot of time in VersionOne. We understand that it is due for replacement with Jira in the near future, although we now very little about this at the moment.
4.3 Sprint Backlog
At the start of each Sprint we construct a very simple spreadsheet that lists the User Stories in the Sprint and how many Story Points are assign to each. Each story has a tab in the spreadsheet with a task list and hour estimates on it. Each team member updates the spreadsheet a couple of times each day with revised estimates.
The spreadsheet also show to whom each User Story is assigned (developer and QA). The status of the Story is also shown (Not Started, Started, Awaiting Approval From Product Owner).
4.4 Burndown
The Sprint Backlog spreadsheet also contains a burndown graph. Before we were a global team, we used to draw this by hand on a big whiteboard to maximise visibility. We now maintain this graph in the spreadsheet so that the team in the USA can also see it. This graph burns down Story Points rather than Hours. Until recently we burned down hours, but we wanted to increase the focus on User Stories and reduce the focus on technical tasks, so we made the change. This is working pretty well for us so far. For this to work you must slice your User Stories to a small size...
4.5 Definition Of Done Checklist
We have a Definition Of Done that comes to around 35 individual items. Not all items are applicable to all work. To ensure that work really gets "done", we introduced a simple checklist that developers fill in when they think they have finished the User Story. Invariably something comes up from the checklist that means the developer has a little bit more work to do!
Our definition of done checklist is available here.
Our definition of done covers checking that development standards and procedures have been followed, however, the most important pieces of the definition are (paraphrased):
- Development work complete
- QA complete
- Work transferred to Product Owner’s approval server
- Product Owner approves User Story
5 Our Scrum Process
We have the following processes:
- Estimating
- Sprint Planning
- Sprint
- Daily Scrum
- Sprint Review
5.1 Estimating
We estimate using relative Story Points. We have established a single baseline story that we estimate all other stories against. We use the Mountain Goat planning poker cards for estimation. Our sequence is therefore:
- 0, 0.5, 1, 2, 3, 5, 8, 13, 20, 40, 100, Infinity, Unknown
Some Scrum teams estimate during the Sprint Planning session. We have stopped doing this since it adds considerable time to the planning meeting. We now estimate as required by the Product Owner. The Product Owner usually gives us a day or two's notice when he needs us to estimate stories. He supplies a brief User Story Word document in advance.
All of the team estimates at the Estimation session. The UK team use the voting cards and the USA team use http://www.planningpoker.com. We try to keep discussion to less than five minutes per story. Anyone can start the http://www.planningpoker.com two minute timer at any time to force a vote.
If all the votes are within three cards then we take the mode (i.e. the most common) card as the estimate. If the difference is greater than three cards then the high and low card holders discuss their reasons for their vote. Following this we vote again until we are all within three cards.
Any Story including and above 13 points is automatically considered for splitting. Smaller stories are lower risk and easier to manage. The Team and the Product Owner discuss how best to slice large stories into smaller stories.
The estimating session is run by the Product Owner, although the Scrum Master sets up the phone conference, Live Meeting etc. The estimating session should be time-boxed, but we are not doing too well with that at the moment...
5.2 Sprint Planning
Although some teams do all of their estimating during their Sprint Planning session. We do not as this tends to unacceptably extend the planning meeting. We aim to complete planning within two hours which is a good proportion for two week sprints. Our Sprint Planning tasks are:
- Define Sprint Theme
- Determine Team Capacity
- Define Sprint Backlog
Our Sprint theme is loose and not every User Story is part of the theme. In fact, we don’t even worry if we don’t have a theme at all! It is a “soft” part of the process designed to focus the team, but we do not find it vital for quality or productivity.
Our definition of Team Capacity is very simple. We assume that our capacity (or Expected Velocity) is the same as our Velocity from the last Sprint (obviously our first Sprint was based on guess work!). We measure Velocity in terms of the number of Story Points we expect to complete. In the past we have determined how many hours the team had available. We also took an average over a few sprints of our velocity. We then worked out an expected Velocity for this Sprint. Although this method did not take a long time, analysis shows that using our previous Sprint’s Velocity as the next Sprint’s expected Velocity is just as accurate as trying to work it out (the infamous “yesterday’s weather”).
We then take User Stories from the Product Backlog that have estimates adding up to the Expected Velocity. We don’t worry too much if we are a point or two either side of the Expected Velocity.
5.3 Sprint
During a Sprint we aim to work only on stories in the Sprint Planning. Our Scrum Master is excellent at shielding the team from demands from the rest of HR SoftCo. Despite this, occasionally we have to help with an escalation for a particular client, but this work is not usually onerous and is usually dealt with within an hour.
Our Sprints are two weeks long. This gives us nine days for development and then one day for Sprint Planning and Sprint Review. In fact we get nearer 9.5 days of time on the Sprint as the Planning and Review only takes half a day.
The two week duration is designed to give the business the maximum opportunity to make changes to priorities. Our team works on three core products with hundreds of features so it is important that the business has the opportunity to flex the team according to shifting priorities. The short two week duration also keeps the team focussed on delivering software and not developing overly complex solutions!
5.4 Daily Scrum
Our daily Scrum is very similar to the standard model other than it includes a very short brief by the Scrum Master at the start. The Scrum Master reviews the current burndown and highlights any User Stories that have not made progress for more than one day.
Each team member then takes a turn answering these three questions:
- What have you done since the last Scrum?
- What are you doing until the next Scrum?
- Do you have any impediments?
This is a critical risk management exercise for us. In the past we have duplicated work for days without team members realising it!
Team Members can usually sort out their own impediments, but occasionally we need the Scrum Master to step in to sort out a problem caused by something external to the Team.
5.5 Sprint Review
Our Sprint review takes around two or three hours. The areas covered are:
- Demo Complete User Stories
- Show Quality Statistics
- Determine Team Capabilities
- Retrospective
5.5.1 Demo Complete User Stories
We demonstrate only complete user stories. At the moment, the individual developers demonstrate their own work, but in future we would like the Product Owner to start demonstrating the software. This illustrates that the Product Owner has taken ownership of the software.
We demonstrate to anyone who is interest in watching. This includes senior managers, product strategists etc. Unfortunately we have found that they do not have a complete understanding of our products (remember the HR SoftCo purchased them as part of a buyout of a UK company). This means that people watching the demos can offer criticism of non-critical parts of the software that they do understand rather than looking at the elements that are important to real customers!
To help mitigate this problem, the developers spend a lot of time preparing for demos which is not the pure Scrum model.
5.5.2 Show Quality Statistics
Until recently we would show Velocity as part of our Sprint Review (to the same people who watch the Demos). Unfortunately, these people are not always familiar with Scrum and Agile. We were finding that our team was being judged not on the quality of work, but rather on whether or not our Velocity was increasing!
We are blessed with a great VP of Development who solved this problem for us! His advice was to not show velocity, but to focus more on our quality statistics (principally test coverage and number of tests). It should be noted that at the moment HR SoftCo as focussing strongly on Quality and Performance of their software, so this all makes sense in terms of the corporate culture.
5.5.3 Determine Team Capabilities
We evaluate our team skills and tools at the Sprint Review (just with the Team rather than with all the “outsiders”). This is usually simple and obvious and we have little opposition to getting and training or equipment we need.
5.5.4 Retrospective
The longest part of the Sprint Review tends to be the retrospective. During this we consider these questions:
- What should we start doing?
- What should we keep doing?
- What should we stop doing?
The team usually agrees on problems raised, although we frequently disagree on solving them! Fortunately our two week Sprint length means that we can try solutions and evaluate their effectiveness without taking large risks.
We sometimes modify our “Definition Of Done” as a result of the retrospective. This is usually where we find a hole in our software quality and we determine a process to plug the hole.
6 Scrum Tools
We consider the following to be essential to our Scrum team:
We use Word for writing User Stories.
We use Excel for managing our User Stories and Burndown. We also use it for manual test scripts.
We use Estimating Cards and planningpoker.com to run our estimating sessions.
We use whiteboards for impromptu design sessions and for writing up task lists for User Stories which a large number of people are working on.
In the past we have used:
- A storyboard
- User Story cards
The storyboard was a large whiteboard. It had a Story card on for each User Story. The cards would move through different statuses (Not Started, Started, Awaiting Final QA, Awaiting Approval, Approved) as work was done on them. This was great for visibility, but not for visibility for a globally distributed team! We now have the Storyboard as an Excel spreadsheet.
7 Related Topics
This paper has discussed how our team at HR SoftCo has implemented the Scrum process. Our day to day development activities will be discussed in the following articles:
- Test-Driven Development At HR SoftCo
- Automation At HR SoftCo
- Extreme Programming At HR SoftCo