Improving Agile Retrospectives With SMART Goals
Agile retrospectives are one of the best feedback loops built into Scrum. It allows delivery teams to pause from their day-to-day work to inspect and adapt their way of doing things. One of the final deliverables of an effective retrospective is a plan to implement improvements on how they build their products. Some of the things a delivery team may choose to look at are:
- Tools & Techniques,
- Processes & Practices,
- People & Communication,
- Quality & Risks,
- Project Scope & Schedule,
- Technical Debt & System Architecture,
- Organizational Culture & Priorities.
A Caution For New Scrum Masters
While the above listed topics usually elicit deep, and sometimes passionate discussions, new teams may fail to actually develop and implement an effective plan to address the insights they generated. When I first started running my Agile retrospectives, my delivery teams would generate valuable insights, have deep and meaningful conversation, and then leave feeling a bit exhausted but generally glad that some dirty laundry was aired.
The result was mostly positive. Team members would develop better working relationships with each other and be more open to practicing empathy on a day-to-day basis. However, after a while, I observed that the discussions kept gravitating towards the same things over and over again. I realized some teams weren’t developing and implementing any plans to improve themselves.
As a scrum master, I was letting my teams down. I was facilitating great discussions and watching the teams develop better working relationships. Of course this was an accomplishment, however, that accomplishment was blinding me to the fact that the teams were maturing and ready to tackle process related problems. They moved past their interpersonal differences and were ready to tackle deeper issues. It was easy to recover from that fumble and SMART Goals helped me do it.
SMART Goals
A SMART goal is an acronym based goal setting guide. It stands for: Specific, Measurable, Attainable, Relevant, and Time-bound. It’s simple to use and forces teams to think, plan, clarify, and begin measuring their goals. To help your team set a SMART goal in a retrospective setting, I recommend allocating the last 20 minutes of the retrospective and writing the following quote and the word “SMART” on a white board.
“A dream is just a dream. A goal is a dream with a plan and a deadline.”
– Harvey Mackay
S – specific
We want to be as precise as possible with what the team is trying to fix or improve on. One tool I use comes directly from scrum — I have the team write a user story.
As a <delivery team> we want to <address some issue> so that we can <some improvement to be made>.
This should be done in an iterative fashion if the user story is not specific enough. Asking the below questions will help the team zero in on the specifics of their SMART goal.
- Why do we want this?
- Who is involved?
- What resources are constrained?
- Why is the goal so important to us?
M – measurable
What gets measured gets done. Think of this portion as the acceptance criteria of the user story. The measurements will be unique to the goal, but try to use quantifiable items. Ask questions about the desired end state. If the SMART goal is centered around the project you can use the 10 knowledge areas
- Project Integration Management
- Scope Management
- Cost Management
- Schedule Management
- Quality Management
- Risk Management
- Resource Management
- Procurement Management
- Communication Management
- Stakeholder Management
A – attainable
This is our first check point — the team should reflect and assess if their SMART goal is realistic. Like effective user stories, we need to check if the SMART goal is independent and free of dependencies. If the SMART goal isn’t free of dependencies, the team may need to return to the Specific portion of their SMART goal and address any dependencies that exist.
R – relevant
This is our second check point — the team should reflect and assess if their SMART goal is germane to the insights discussed during the retrospective. As a Scrum Master, you can ask questions like:
- Is this a worthwhile effort?
- Are we the right group of people to take on this effort?
- Is this the right time to address this effort?
Again, if the team doesn’t define the SMART goal as worthwhile or discovers they are not the right group of people to take on the effort, they should return to the Specific portion of their SMART goal and identify something within their span of control.
Note: if the team discovers that another group is more suitable to address the issue discussed, the Scrum Master should take the generated insights and work with that group after the retrospective adjourns.
T – time bound
The final step is to establish a target date. Teams tend to work better when there’s a deadline in place. The team, armed with the specifics of their SMART goal, defined metrics, and an ideal end state should be able to set a realistic date. In my experience, the date should be no more than 2-iteration lengths (4-weeks total assuming 2-week iterations).
Leave your thoughts on Agile retrospectives or SMART goals in the comments below or if you’d like to have a discussion, please contact me or connect with me on social media!
Photo Credit: Flickr
jeremy brien 
6 thoughts on “Improving Agile Retrospectives With SMART Goals”