Retrospectives work item usage
I'm trying to understand and make the best (intended) use of the Retrospective work item. From the RTC documentation, a Retrospective work item "records what went well and what did not go well in the recently completed iteration".
Is the idea that there would be one Retrospective item per iteration? And then, from that work item, new tasks can be extracted from the Retrospective item for future iterations to address any "did not go well" issues? A Retrospective work item doesn't have an Estimated Time field, but it does have a Planned For field and an Owner. If the work item is there to capture information, I'm not understanding the Owner and Planned For field purposes. Are they just there so that queries can be constructed to show "Retrospectives in this release" (or something similar)? Or, would another approach be to create multiple Retrospective items to document work that the team has agreed upon to improve on "problematic" areas (ones discussed during a retrospective mtg)? It feels like stories added to the backlog are a better fit for this approach. ( I feel like a better approach (for my team) would be to document the Retrospective meeting discussions and findings in a new page for the Sprint iteration plan. We could still extract work items from the page and it keeps a record of the lessons learned topics alongside the plan overview and planned items. Any insight on best practices for using Retrospective work items from others? Thanks, Jim |
2 answers
Interesting topic. For selfhosting we started out with the approach you
propose. We added Retrospective pages to the iteration plans. Over time we learned that we wanted to ask questions about the current state of the retrospectives (each jazz component team as well as the PMC have a retrospective meeting). Which teams have not yet done their retrospective? Which ones are in progress? Which ones are completed? So, we wanted to query the state of the retrospectives. This is how the work item type was born. The 'Planned For' field is used to express which iteration the retrospective is about. The 'Owner' is the person who runs the meeting. We also learned that because we now use a work item to capture the retrospective, team members take more often the chance to comment on the retrospective protocol or to provide input when they cannot make it to the retrospective meeting. There is one other point of interest: Work item types are more explicit than the convention to attach a new page to the iteration plan. What we learned in general is that if you care about something you best make it as explicit as possible. Kai Jazz PMC jimmcvea wrote: I'm trying to understand and make the best (intended) use of the |
|
Thanks for the insight, Kai.
At this time, due to the way my team is structured and the size of the team, we don't have the same needs as the Jazz PMC team and the simple approach of a Retrospective page will suffice for us (the wiki editing is nice for formatting our information and findings). I definitely agree with your comment about being explicit when you care about ensuring some action happens. For this reason, I'd like to see a dedicated Retrospective page created for each iteration plan instead of using convention to create one each time. I *think* I might be able to accomplish this by writing a custom behavior operation triggered when an iteration plan is created .. but I've got some investigation to do to learn more about it first. Thanks again! |
Your answer
Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.