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. (we keep team improvement items in our backlog along with stories for the product we're building )
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
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:
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
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. (we keep team improvement items in
our backlog along with stories for the product we're
building)
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
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!
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!