On 20 July 2013, I delivered my first workshop for General Assembly. The “global education network that transforms thinkers into creators through education and opportunities in technology, business, and design” launched its new campus in London in June 2012 (only their second after NY) and already has a wealth of courses from data analysis to web dev, UX design to digital marketing.
I hosted a workshop covering the very basics of agile and Scrum. Using an adapted version of Vera Peeters and Pascal Van Cauwenberghe‘s XP Game, we used a variety of stories to explain concepts such as sprint planning, estimation and velocity (for more information on what we covered, see ‘The Basics’ tab).
Lots if questions were asked but, unfortunately, we didn’t have time to answer all. So, I thought I’d answer them here.
“How do the ScrumMaster and PO roles relate to backlog?”
I’m guessing that this question was raised early on in the session because I’m hoping the workshop demonstrated that the PO is responsible for maintaining and prioritising the product backlog, whilst the team is responsible for agreeing the sprint (or iteration) backlog.
However, sprint planning itself can be an iterative process, where the team provides estimates, then the PO deprioritises / descopes / splits stories so that the most benefit is delivered.
“What the ScrumMaster is also a line manager?”
We try to steer clear of the ScrumMaster being the team’s line manager because this role is not a ‘leader’ position in the traditional sense; which is why we often hear the term ‘servant leader’.
“Can people share roles / Must the PO and team be two different things to make it work?”
When I first started using Scrum, it was quite common for a dev to perform the role of ScrumMaster. This worked to some extent, with the dev spending the required time to remove impediments. However, this method didn’t work so well in terms of protecting the team against an over-eager PO who kept wanting to change the sprint backlog. The problem was exacerbated by us changing ScrumMasters each sprint, so the PO used to interrupt whichever dev was closest at the time. In short, your ScrumMaster can be one of the team, but it works better if they are a stand-alone position that can also help you with improving your use of Scrum.
In terms of the PO, I’d definitely not recommend this role being any of the team or the ScrumMaster as there will often be a conflict of interest.
What role does the Product Manager play?
This question came from a chap who had just started a new job where he reported into three Product Owners and acted as a proxy for them.
When POs are on the board/senior exec team, and are therefore unavailable much of the time, it is quite common for someone to act as proxy: after all, it’s better to have someone who can make decisions when the team needs answers. This can work as long as the proxy has the knowledge and power to make decisions which will be accepted by the PO.
In this instance, I’m more concerned about the number of POs that our friend is working with: three. Unless he has sufficient knowledge and standing in the company, I can see him struggling to juggle requests from three different sources into a single Scrum team. Ideal world: one PO per Scrum team. Someone needs to be able to make a final decision that A takes priority over B.
If stories aren’t assigned to individuals, how does it work when you have specialists on the team?
There is a risk, if the team contains specialists, that certain stories can only be completed by certain individuals. This is not ideal.
Having such a dependency means the team has a single point of failure and isn’t good for any team (Scrum or other).
Can the expert work with others in the team to enable them to pick up future stories? The expert can oversee the work, and provide recommendations on direction, but this would enable others to pick up the story.
A nice analogy I read recently was that of a football (aka soccer) team: “A football team structures themselves into the specialised skills set. Defenders will often stay back and attackers will move upfront. However when the team find themselves in a certain position, the team adapt and play out of position to support the ultimate goal of the team which is to score as much as possible and not concede goals.”
In reality, you will often find that stories need a bit of input from many people across your team (especially when you start splitting stories vertically)
Impossible/infinity score in planning poker
In our workshop’s planning, I only gave options of 1, 2, 3, 5, 8, 13 and 20. However, Mike Cohn’s Planning Poker also has options of 0, ½, 40, 100, ? and infinity.
We use the “?” when we have absolutely no idea of the complexity. This will normally result in a spike, where a fraction of the story is tackled in order to give us enough information to be able to estimate.
“Infinity” is shown when it will take too long to complete the story – it is very rare that this card is used, but it would mean that the requirement is unfeasibly large and needs to be split up or an alternative route needs to be taken.
Breaking down stories (e.g. splitting 40 sums into 2 stories of 20)
Scrum aims to deliver benefit to the user at the end of each sprint. If a story is too large to complete in one iteration then it should be split into smaller stories. However, resist splitting everything into 1 point stories as this just increases admin unnecessarily; a good rule is to make stories around 1/6 to 1/10 of your velocity.
“This was a 3 point story but now we have experience it is only 2 points”
The size of a task doesn’t adjust with experience; improvement is reflected through velocity. A 5-point story in iteration 1 is still a 5-point story in iteration 400. But your velocity will hopefully increased so you may have gone from completing 25 points to 40.
Kanban
Yes.
I am not sure what the question is, but suspect it was a note to suggest we have a discussion if we had any spare time. Maybe General Assembly would like to run a separate workshop on Kanban?
Advice on working across time zones
This is another topic that I cannot do justice in a few words. This is the kind of discussion that we have at London Agile Discussion Group. You are all very welcome to come along to future discussions.