Recently I have been working on a project for a new client delivering replacement digital processes for their paper based predecessors. Due to the nature of the work I am unable to provide specifics about the projects but can divulge the approach the team has used to achieve this work.
On day one of my assignment the team and myself were cobbled together and asked to finish off the project which was started six months ago or so. The project has been dormant whilst a third party went away and developed their part of the system in an waterfall way (perhaps i’ll save that experience for another blog!). Whilst a backlog existed it hadn’t been refined for around six months and contained some items that were done, some that weren’t required and was missing a lot of stories that we had to do.
I’ve recently purchased and read Scrum by Jeff Sutherland and wanted to let you al know my thoughts.
First of all Jeff Sutherland along with Ken Schwaber invented Scrum back in the early 90’s making them the Scrum Gods and Jesus all rolled into one. Since then they have spread Scrum through various companies and organisations like Scrum Inc and involvement with others such as the Scrum Alliance. There are many people out there who are prepared to give you an opinion on Scrum (after all you are reading my own blog dedicated to my experiences with Scrum) but getting insights from one of the creators is invaluable. The insights gained from those first few sprints, the realisation of needing roles such as a Scrum Masters and Product Owners to the experiences of implementing Scrum in failing, successful and companies anywhere in between are what make this book such a great read in my opinion.
Hours or points for sprint planning seems to be quite an opinion splitter in the Scrum community. Even the Scrum heavyweights Mike Cohn and Jeff Sutherland have chipped in with their opinions with both landing on either side of the argument.
I’ve discussed this a few times on the Scrum Alliance LinkedIn group and whenever I put my point across I’m not sure if my point has ever really come across. To be clear I always estimate stories in points (i’ll save the reason why for another blog) and always use story points for velocity calculation. I then always break tasks into hours. At the start of any sprint planning session I will always show the team their historical velocity for the last few sprints (no more than 5) and ask the team if there is any known absence for the next sprint. At this point I will ask the team what they think they can achieve in the coming sprint. The Product Owner should know the teams velocity and should have a good idea of what this team usually achieves in points to help them decide what to bring in.
One of the scrum ceremonies the Scrum Master facilitates in the sprint Retrospective. I don’t think its fair or accurate to say that one of the ceremonies is more important than the other as they are all a vital part of the Scrum process. However, as an empirical process the retrospective is the real chance for the team to inspect and discuss their practices whilst agreeing achievable improvements they can make to their process for the next sprint. A team which doesn’t utilise the retrospective does so at their peril.
A User Story is a common method of turning traditional user requirements into a feature for an Agile team to work on. It is written from the end users perspective and describes the value of the work to the business along with the acceptance criteria that satisfies the story.
The Product Owner is a key role in a Scrum team. I am not saying it is the most important role in the team (Scrum doesn’t advocate team hierarchy or reporting lines) but in my experience I have found that a Scrum team works more effectively with a strong Product Owner. Whilst they aren’t required or expected to lead the team, showing strong knowledge of their product and ownership of the work they ask the team to do are key components for an effective PO/scrum team relationship.
I’ve been lucky enough to have work in a few organisations where Scrum has been implemented from scratch so feel I’ve got a good idea of what it takes to implement Scrum in such organisations. Below are a few tips that I’ve found helpful….
I previously blogged about my upcoming Product Owner course which I completed last week. The course was run by Agil8 and David Hicks in Central London. Having already used Agil8 for my Scrum Master certification I was familiar with David and his approach to training.
I’ve never performed the role of a Product Owner but with the relationship between Product Owner and Scrum Master being so vital I felt the course would be beneficial to gain a further grasp of the PO role. There was quite a lot of overlap between the CSM and CSPO course content so whilst a fair chunk of the course material wasn’t new to me, it’s always nice to re-affirm what you are doing and why you are doing it that way.
Recently the team I am the Scrum Master of has started using an electronic tool for tracking stories, tasks and sprints. Whilst I do not object to using such tools for Scrum I feel a common misconception is that these tools are required for Scrum to be successful. My personal preference is to run a manual Scrum board located very close (if not in) the area the team operates. I find this works best and keeps the process low ceremony and acts as very valuable information radiator for the team, stakeholders and anyone within the organisation. The temptation with just an electronic board is to leave it all in the tool which means if you do not have the URL of the tool you have no idea of progress of the current sprint or what is in the backlog.
I also find tools to some degree contradict part of the agile manifesto
Individuals and interactions over processes and tools
Tools can be valuable but are they essential?
I’ve used JIRA in previous teams and have found it to be one of the better tools I have used. It is a very mature product from Atlassian which means it has a very strong base. The JIRA Agile plugin (or Greenhopper as it was previously known) is a must. This plugin allows electronic versions of the backlog and scrum boards (it also supports Kanban) with a drag and drop interface for ease of use.
To be fair to JIRA and other tools they do provide some positives
- For distributed teams or distributed members of a team it can be very difficult for them to see the physical board so an electronic tool can be useful here
- Tools such as JIRA Agile allow story artefacts such as designs, documentation, wire-frames to be attached in one central location rather than emails or print outs.
- Most tools auto-generate the sprint reports such burndown charts, velocity reports etc
All in all I think a tool can help a Scrum team but I always manually replicate anything in the tool to a physical board. It’s more work for a Scrum Master but I class the board as an integral part of the process for which the Scrum Master is responsible for.
The Product Owner I am working with at Monarch has recently tidied up the backlog board and made it nice and easy to understand.
Here is a picture:
The layout is nice and simple and becomes a very valuable and important information radiator for the team. It also advocates the Scrum principle of “transparency”. Anyone can see where an item of work on the backlog is and its current status (on hold, requires estimation, not ready for dev and ready for dev).