This photo is the list of actions/changes/learnings one of my teams came up with in their most recent retrospective. This did not come from someone who went on training or read an article. It also didn’t come from a new Agile coach or Scrum Master. It came from them missing their sprint commitment and goal. This team only managed (on paper) to complete 8 out of 18 points; but they all knew they had delivered and learned a lot more than that measure reflected. Here are some things that they decided to do going forward:
1. If the team cannot reach consensus about the size of a story, then split it into two stories and size the smaller stories
One of the main reasons the team had such a poor burn-down is that they took in one quite large story which did not quite meet the INVEST requirements. For one, it was a ‘common component’ that was to be used in most of the later stories (so not independent). It also was not small enough – and turned out to be even bigger than the team had thought. During sizing, there had been some debate about its size and eventually reluctant consensus was to make it the smaller size. Turns out the less optimistic team members were right. This was one of the stories that was not done at the end of the sprint.
2. Keep Planning II – and use it to verify the sprint commitment
This is a team that often decides to skip Planning II (I don’t like it, but ultimately it is the team’s decision and so far we’ve muddled along without it). For this sprint, they decided that they did need a session to unpack the stories and how they would be implemented. Everyone agreed that without Planning II we would have been even worse off. They also realised that at the end of Planning II, there were already some red flags that the big story was bigger than everyone had thought and they could have flagged, at that point, that the commitment for the sprint was optimistic. The team agreed that, in future, if going into the detail during Planning II revealed some mistaken assumptions, then the team would review the sprint commitment with the Product Owner before kicking off the sprint.
3. Feel free to review story-splits in-sprint
Early in the sprint, the team were already aware that the big story was very big and probably could be split into smaller components. Their assumption was that this wasn’t possible once the sprint had started. For me, re-visiting a story split mid-sprint or once you start the work is not a bad thing: sometimes you don’t know everything up-front. It also, in the case where a story is bigger than expected, gives the Product Owner some more wiggle room (negotiation part of INVEST) to drop/keep parts of the story to successfully meet the sprint goal. Of course, where we have got things really wrong, then sometimes the sprint goal cannot be rescued and the sprint would be cancelled.
4. Raise issues as they happen
Pretty much summarises most of the above points. One of the agile principles is responding to change over following a plan, so when change happens make it visible and decide how to adjust the plan at that point. There’s no point in battling on as planned when you know that the planned path is doomed to fail.
Some references:
- INVEST
- More INVEST
- Some options for when you’re struggling to create an INVEST story
- INVEST stories and SMART tasks
- Always useful story-splitting cheat sheet
- And something on failure
Reflections of a Scrum Master 
Kewl. How do you build that kind of culture in the team?
Hi Joshua
A proper response to your question would probably require a blog post of its own! That and the true answer is probably ‘it depends’. In this context, factors that I believe contributed to this team’s ability to provide insights were:
1. The team includes some senior team members that have experience working on other Agile teams and/or in other organisations (diversity means different perspectives).
2. We have been emphasising our release plan and stakeholder expectations quite heavily over the past two months and have tried various ways to make the timelines, work, stakeholders and impacts very real to the team.
3. Ultimately, deciding what will go into a sprint is in the hands of the team. They did not have the excuse that they were forced to take on stories they did not believe they would finish.
4. Our reviews include our direct stakeholders. In this case, we are writing the front-end of the CMS for our new website that will ultimately be owned by Marketing. These users and stakeholders are invited to reviews and are free with feedback in the sessions.
5. One of our company values is Performance Driven, so we tend to hire people who like to get things done.
6. We used open-ended questions and gave the team time to decide for themselves whether they had not achieved their sprint commitment and what that meant to them.
Hope that helps 🙂
Mya
It really helps. So the key is to have the right people in the organisation. But it also seems the stakeholders is very open minded with the process. How do you educate the stakeholders to embrace the process and make the workplace to be a safe environment? You have done a good job educating the developers and the stakeholders.
I’m afraid I can’t take much of the credit in terms of educating the stakeholders: the Agile transformation has been happening since around 2008 at the company where I currently work and I’ve only been here for the past 18 months. A strong value system helps – and consistently living out those values (not merely having them as a list somewhere). With regards to the team, that’s where having experienced and brave team members that others can role model is really, really useful. As a Scrum Master, you also need to be prepared to trust the team. As a general rule of thumb, I find people behave as you expect them to behave (because usually how we expect them to behave influences how we treat them).