Some time ago I sat in on a development team’s sprint planning meeting for iteration 17 of a new product at a large organisation. The team was a normal sized team with 5-7 developers, a Scrum Master and a Product Owner. I’d say the developers are experienced but not senior, the person assigned as Scrum Master has been in IT for many years, and the Product Owner, who is from another department, has also worked for some time at the organisation.
The sprint planning meeting were scheduled for four hours. The sprint lengths were three weeks, with only a few exceptions (e.g. a longer summer Sprint), so a four hour sprint planning seemed reasonable for a team using product backlog refinement meetings.
The IT department is not new to Scrum and appreciates the the value of being agile. Other agile methodologies are also used in other parts of the department.
In sum, all sounds great. But… rumours said that it didn’t go as planned, the product wasn’t nearly as finished as were hoped for. This is why I asked to sit in at the meeting, and had beforehand decided to just observe and take notes during the meeting. I jotted down three and a half pages with questions, thoughts and other odd notes, but the very first entry sums up the entire meeting in a somewhat horrific way:
“What is the purpose of this meeting?”
The first, and bigger, part of the meeting centred on what could be called typical Product Owner issues. Why this happened was due to the fact that members of the steering committee were present as contributors to the meeting and not as observers. This resulted in a number of discussions, both technical and solution oriented discussions in which the developers hardly spoke at all.
I’m a firm believer of that the development team is responsible for the solution and implementation of set requirements. If the organisation (e.g the steering committee) has any special input on how the solution should be implemented it should already be in place before the start of any sprint planning meeting. Of course the organisation can, and should, consult the development team regarding these things, but not during the meeting.
During the end of the first part the team had a sort of sprint review, which was called “demo”. Three different developers showed some functionality each one of them had been working on during the last sprint. This took 15 minutes in total. Members from the steering committee interrupted during the presentations.
After close to two hours of meeting it was time for the first break, for lunch. Breaks are important for many reasons and should not be forgotten.
Following the lunch break the actual sprint planning meeting began. Developers and Scrum Master were there, but no Product Owner. At first, I didn’t think anything of it, but after a while I understood that the Product Owner had entered new, not previously discussed items to the product backlog. A Product Owner can in some cases choose not participate in the sprint planning if the team have had enough opportunities to understand the backlog items at hand, e.g. through product backlog refinement meetings.
The team is using the Team Foundation Server (TFS) from Microsoft for source control, and, as you probably know, TFS has many Scrum and agile features built in. The Scrum Master displayed the product backlog from TFS on a projector canvas which was the centre of attention for the whole team.
To help this team improve on how to do a sprint planning meeting a couple of things needs to be addressed.
During this meeting the assigned Scrum Master was more of a secretary than a facilitator or servant leader. It is often stated that Scrum is simple but not easy, and I think that this Scrum Master would benefit greatly from attending some training, read some introductory texts on Scrum and more in depth when it comes to the role of the Scrum Master.
The Scrum Master must realise the responsibility of the role, especially at iteration 17 and the team still haven’t worked out how to conduct a sprint planning meeting.
Members of the steering committee should have presented their requirements to the Product Owner outside this meeting, in another forum.
As a rule of thumb one could say that if the product backlog will be involved in a meeting then the Product Owner should be present in that meeting.
For this team the presence of the Product Owner would also make the team more at ease.
The use of TFS as a source control is not the issue here, nor the different agile features in it. The issue is rather on how to get the team to interact and not focus on a projected image on a wall.
With sticky notes things like spelling and phrasing is less important. The developers can easily jot their thinking on a note at stick it on the wall next to the item number from TFS written on paper or whiteboard.
The sprint planning meeting as a whole will be discussed more in the future. This article was only a short report from me sitting in on a team’s sprint planning meeting.