October 17, 2013 
This is the fifth and final part of the series TFS as perfect tool for Scrum. The series is based on my session that I presented at Microsoft TechDays.
You can find more introduction in part 1
The agenda for this series is:
1. Introduction in Scrum and TFS
2. Using TFS for grooming your Product Backlog
3. Using TFS in Sprint Planning
5. Using TFS in your Sprint Review and Retrospective
Today, Part 5 – Sprint Review and Retrospective
Disclaimer: Within these series I talk about backlog grooming a lot. Nowadays this is known as backlog refinement and refining. Where grooming is used, you can replace that with refinement.
Part 5 – Sprint Review and Retrospective
Finally you’re there. The sprint is ready. The work has been done and the timebox for the sprint has expired. Time to relax…or not. The most important pieces of the scrum cycle are yet to come Sprint Review and Sprint Retrospective. The events are essential for Scrum teams to keep growing in their performance. The Review & retrospective focuses on looking back and looking forward, inspect the deliverable and inspect the process.
Sprint Review
The Sprint Review is the first event that takes place. This event is focused on the dialog between the stakeholders, product owner and development team. A sprint review takes up 2 hours for a two week sprint and focuses on getting feedback about the deliverable and getting insight in what is coming up next.
Usually an agenda of a sprint review meeting can look like this:
- Walk through the Done (!!) PBI’s of the last sprint and provide a demo to the stakeholders
- Discuss what has been done and what has not been done
- Gather feedback from the stakeholders for future improvements
- Discuss future sprint(s) and new areas
Challenges in Sprint Review
Sprint review can quickly become an event that is seen as a burden. Most of the times the reason is simply because the review meeting is not “interesting” enough.
Be aware that the sprint review is an interactive meeting and not just a sole demo. Also be aware that sprint review is done with stakeholders who usually do not have (and want) insights into the code. Therefore make sure you have a nice demo that focuses on the functional parts of the application and do not dive too deep into the details about how the application was built.
Make sure there are stakeholders present during the meeting. When you do a demo only for the development team the meeting does not provide the value you want and need.
Ask the same questions at the end of the demo to your stakeholders every time you do a review. They can already prepare. Questions that you can ask are for example:
- What did you like the most ?
- What did you not like?
- What would you like to improve?
This blog describes what a Sprint Review can mean for your team. Also take a look at these tips !
Besides the content parts, there are also some questions I always get regarding the implementation of sprint Review.
- How do we deal with unfinished work?
- Where do I store the review feedback?
- How and where do I get the Increment?
- Where do I put the deliverables
Sprint Retrospective
What Sprint Review is for your application, Sprint Retrospective is for your process? During this event, the Scrum teams inspects their process. What did we do? How did we do it? What went well? What went wrong? The retrospective is the perfect moment to capture feedback about the process but also about the people!
When teams make a start with Scrum, the process must still be finalized. Norms have to be created within the team. Agreements about the way of working. The first retrospectives are usually very useful. People look at their process and identify the simple improvements. We need automated tests!, The build does not work properly! We need to create more tasks etc. Easy to identify but most important…Non-personal.
There are many books, websites and techniques to do a retrospective. Some of the techniques that are great to use in a retrospective are:
The hard part for the Scrum master (and essentially the team itself) is to keep the retrospective interesting. Where the majority of (IT) people love to talk about defects in the process, improvement areas, tooling etc., only a small group likes to talk about…themselves, or others. However, to get the most out of your team (happiness, productivity etc.) the personal side is really important too!
What I usually do is highlighting one subject in a retrospective. For example. When I want people to think about improvement areas I use the Starfish. When I want to focus on the team, I use a more personal exercise or play a game. This site is full of great agile games that you can play with your team !
Also this book by Esther Derby and Diana Larsen about Agile Retrospectives is worth a read !
Challenges in Sprint Retro
Retrospective is very useful to improve as a team. But not everybody is eager to share his thoughts. Beware of “silent” people and make sure everybody has an equal part in the sprint retrospective meetings. Allow time for people to write down their thoughts first, instead of directly in front of the group.
Same as with the Sprint Review, technical questions arise here as well.
- Where do we store the outcomes?
- Can we give people some tools to reflect before the meeting?
Use Team Foundation Server
In the previous paragraphs I talked about the Review and Retrospective and the “technical” challenges. Before I explain how Team Foundation Server can facilitate some things for the Review and Retrospective I want to share this with you.
Review and Retrospective are not about the tools !
Try to limit the use of tools (besides paper, sticky notes and a presentation beamer/laptop) during these events. The tools distract you from the real purpose of the meeting. This goes especially for the retrospective where you focus on the process and the people.
Having this said, let’s take a deeper look at some of the challenges we faced.
- Review
- How do we deal with unfinished work?
- Where do I store the review feedback?
- Retrospective
- Where do we store the outcomes?
- Can we give people some tools to reflect before the meeting?
How do we deal with unfinished work?
The most common question after the sprint review. How do we deal with our unfinished work? We have worked on PBI’s, some tasks are ready, some are not, resulting in an undone PBI. Scrum says, when work is undone after a sprint, it has to be put on the backlog again. The Product Owner decides whether it can be picked up in the next sprint.
So, as an example let’s say we have a task board looking like this at the end of the sprint
This means, PBI 2, PBI 3, and PBI 4 should move to the backlog (or next sprint). To keep the data of the last sprint intact, we only want to move Task 7, Task 8, Task 10 and Task 12 (Undone tasks)
In the TFS Web Access Client, you can “drag” PBI’s from the sprint backlog to the root backlog or another sprint BUT …this results in unwanted behavior because it moves ALL the tasks under a PBI.
What you need to do, is create a query that extracts all undone PBI’s with all undone tasks of the sprint. You can create a simple tree query for that.
Resulting in this set
Then you use the bulk edit feature (see my previous blog post here for more details) or the quick navigation [Move to Iteration] to move them to the backlog or next sprint (don’t forget to save !)
The great part is that in the first sprint, the [Done] Tasks are still displayed next to the PBI that was moved to the next sprint !
Where do I store the review feedback?
During the sprint review, you gather feedback. There are many ways to deal with the feedback. You can put in the Discussion field of a Work Item, You can use the feedback tool and create Feedback Request / Response Work Items or you can use the Sprint Work Item that I introduced in part 3 (download here)
This Sprint Work Item is created during Sprint planning and contains a field for the review as well.
You can also put attachments in a work item. Maybe record a video of the demo and attach it as well.
Retrospective tools
To facilitate in the retrospective, we can use the Sprint Work Item again. In the zip-file that can be downloaded here, there is another work item type. Sprint Rating. Where the Sprint work item can be used to write down the outcomes of a retrospective, the sprint rating work item can be used to help people think about the sprint before they come to the meeting.
The idea is to generate a “timeline” and “moodgraph” for the team that can be discussed in the retrospective. The graph can look like this.
What you see is a graph for the team and graphs per person. Per person 2 Sprint Rating Work Items are filled in. One about the sprint and one about how they felt in the sprint (emotional). The sprint Rating item looks like this
By saving 5 measure point in 5 custom fields, we can generate the graph. The RDL file + queries can be found here. I use views in a separate database to query the warehouse. Read my posts about custom reports to implement this mechanism (part 1, part 2 and part 3)
Download the database queries, reports and work items here ! (http://sdrv.ms/17NuuFO)
NB: Don’t use this directly on production but test it first !!
Conclusion
The sprint review and retrospective are all about the inspection and adaption part of Scrum. Where do we stand with our product and where do we stand with our team and process. These parts of Scrum are the parts where tools can merely assist.
Let me quickly review the challenges that I often hear to see if we addressed it all.
- How do we deal with unfinished work?
- By using the power of TFS Queries and bulk editing work can be easily moved from one sprint to another without breaking the historical data
- Where do I store the review feedback?
- When implementing the Sprint Work Item, you also facilitate a location for storing information form the review. Think of text but also of attachments (videos, powerpoints etc.)
- How and where do I get the Increment?
- The build server of TFS makes sure you always have access to the latest build. Take it one step further and you can facilitate a full blown environment with both Lab Management or InRelease
- Where do I put the deliverables
- Deliverables come in all sorts. Put documents on SharePoint, put code and documents that will be shipped in TFS.
- Where do we store the retrospective outcomes and can we give people some tools to reflect before the meeting?
- Use the sprint and sprint rating work item to capture feedback from your team. Use the powerful reports in TFS to make this visible.
This post about the sprint review and retrospective is also the end of the blog post series “TFS as perfect tool for Scrum”. Hopefully you found it interesting. If you did, please leave a comment!
In this series I tried to highlight the power of a ALM tool like TFS but also tried to emphasize the need for process without the tools. Scrum is all about transparency. A tool can provide you with these insights by storing everything in a central place, making it easier to report
Use Scrum to define what needs to be done and use TFS and Visual Studio to define how it needs to be done !
Resources
- Sprint review -What’s in a name – http://stacycashmore.wordpress.com/2013/05/20/sprint-review-whats-in-a-name/
- Tips for a good sprint review – http://scrumcrazy.wordpress.com/2011/04/14/tips-for-a-good-sprint-review
- Retrospective Timeline – https://www.thekua.com/rant/category/retrospective-exercises/
- Retrospective Moodgraph – http://tastycupcakes.org/2013/07/moodgraph/
- Retrospective Starfish – http://lmsgoncalves.com/2013/08/07/getting-value-out-of-agile-retrospectives-star-fish/
- Agile games – http://tastycupcakes.org/
- Agile Retrospectives book – http://www.amazon.com/Agile-Retrospectives-Making-Teams-Great/dp/0977616649
- Bulk Editing work items in TFS 2012 – https://osnabrugge.wordpress.com/2013/09/27/hidden-gems-in-tfspart-10-editing-multiple-work-items-at-the-same-time-bulk-edit-updated-for-tfs-2012/
- Using the TFS 2012 feedback tool – http://tfs.visualstudio.com/en-us/learn/tfs-feedback.aspx
Download the database queries, reports and work items here !
The Road to ALM 
Regarding dealing with work that isn’t done at the end of the sprint, doesn’t moving a PBI from one sprint to another cause the effort applied to the source sprint’s velocity get moved to the destination sprint’s velocity? So for example if a PBI has an effort of 13 and is mostly done at the end of the sprint (say there are only 2 more hours of work to be completed), by moving the PBI to the next sprint the velocity for the current sprint would not accurately represent the amount of effort that was completed. An effort of 13 is the largest amount of effort we allow a PBI to have during a sprint and is assumed to be a around half a sprint’s worth of work (we use 1,2,3,5,8,13,20,40,100).
What I typically do on the day of the sprint review is ask the development team to split any PBI’s that will be incomplete that day. I ask them to update the effort on the original PBI, and then create a new PBI in the next sprint with any remaining tasks. We then reassign an effort to the new PBI.
I am eager to hear your feedback on this approach.
Thanks
That is definitely an approach you can use. On the other hand. Scrum says if a PBI is not done, it is not done. So the story points are not assigned to the sprint. In the long run, velocity will average.
Agreed, and thanks for the reply. We are starting on a new product and in an effort to get a more accurate velocity history we are doing a little extra work with the PBI maintenance. If were are able to get the maximum effort applied to a PBI down to 5 I would be more inclined to use your approach. Unfortunately if we have 5 developers who are working on 5 different PBI’s each with an effort of 13 (a total effort of 65), it skews the velocity too much for our team.
Thanks again, this series has been very helpful.
Thanks for your comments!
Regarding building a query to show undone work, doesn’t the out of the box “Unfinished Work” in the current sprint give you what you need? It shows PBIs, Bugs, or Tasks which are not removed or done and any sub tasks that are not removed or done.
Seems like it :). Thanks !
Regarding unfinished work, it looks like the PBI and the undone tasks only are moved to the backlog. My question is what happens during sprint planning? If you drag the undone PBI into the sprint, will it move all the related tasks, or just the ones in the backlog that are not complete? Or do you have to create another custom tree query to do sprint planning to move these Undone PBIs into the next sprint?
Unfortunately the behavior is that when you move a PBI from the Sprint Backlog to another sprint it moves all tasks. The solution is indeed a tree query that shows all undone PBI’s and undone tasks from the sprint. The good news is that when you do not move the Done tasks in the previous sprint, the Sprint backlog still shows the PBI even though it actually resides in the next sprint!
Hope this helps !
Hi 🙂
Thanks for including my blog in your article 🙂
I saw that you talked a lot about Retrospectives 🙂 You can download our free ebook here: https://leanpub.com/gettingvalueoutofagileretrospectives
I guess you will like it 🙂
Cheers,
Luis
Thanks for a great series. I know that work item time tracking is not part of Scrum, but I (and many others) need to track to time in order to invoice customers. I have looked at all the tools I could find that integrates with online TFS, but all of them seems inadequate either because of missing features or lack of usability. What are your experience with work item time tracking?
Hi,
Sorry for my late reply. There are a number of tools that integrate with Visual Studio Online with regards to work item tracking. I’ve done it myself on a on-premise TFS. What I always try to do is to not intervene with the Scrum process as far as possible. SO on-premise I created a special work item (hour entry) that is a child of a task. Every one can create hour entries underneath this task for hour registration. The remaining work (and burndown etc.) still work on task and are not influenced. By adding some customization with the API we integrated this TFS item with our billing system. For developers this is convenient because they can stay in Visual Studio .
Hope this helps
Hi,
Thanks for the insight. Unfortunately, I do not think that this will work in a VSO context, as I can’t change the API.
I hope that something like http://www.tfs-timetracker.com/ will be available to VSO, alternatively we have to move the tfs on-premise or on Azure PaaS.