Dog-fooding Journal #3 – Train-Research-Planning (TRP) Sprint Journey

Article
04/01/2014

This is a continued journal for our dog-fooding, targeting primarily our Ruck masters and anyone who wants to understand what we do and why Smile

We immerse ourselves into the 2-weeks of preparations enclosed in the TRP sprint and accompany Jon and his vsarSecurity team on their adventure. This is the second team to actively dog-food the project management innovations and we may inject findings from the vsarTreasureMap and the vsarDevOps team to compare.

training

The vsarTreasureMap team requested no training as we are not dealing with new technologies, unfamiliar territory or exploring a black hole. No training session have or will be scheduled during the TRP sprint.

research

The vsarSecurity team started a great discussion thread on email and scheduled a 1-hour Open Q&A session a week before the DEV-1 sprint planning meeting. The latter was precious and though-provoking, allowing the team to discuss their research, findings and agree on the next steps. Most importantly it allowed the critical team members to push back, question value-add and make the entire team remember that value-add, no risk and simplicity are important considerations.

NOTE: As a fly-on-the-wall, trying not to interfere, I found the meeting immensely valuable and hope that other teams will follow suit.

planning

planning the meetings

Working with different personas, time-zones, a distributed and part-time team sprinkles interesting challenges over the scheduling for the program manager (PM) and the ruck master (RM). The PM and/or RM typically support the project lead (PL) by owning and driving this challenge.

Try this challenge:
Schedule a meeting that allows 9 of your team members to meet for an hour, at a reasonable time and which can be repeated for weekly stand-ups. Assume person A is in US West coast, B in US East coast, C in Equator, D in Switzerland, E in South-Africa, F in Russia, G in Pakistan, H in New Zealand and I in Australia.

For vsarSecurity we decided that we need:

An open Q&A session at the beginning of the last week of the TRP sprint, to discuss the research and the process innovations.
A sprint planning session as late into the last week of the TRP sprint as as possible.

What is known?

Attendance by the project lead is required for both meeting.
Attendance by the product owner is optional. While we recommend PO’s to be actively involved, their time is precious and we therefore ensure we indicate which events are optional and which are required.
Avoid scheduling meeting on Friday’s. Encroaching into precious Friday evening family time conflicts with our family>job>rangers mantra.
Ensure we give team members a minimum of one week advance warning of an event, so that they can plan accordingly.

Step 1 – Find out when the PL is available?

We ping the project lead and ask him for good days and time slots to schedule the discussion and the sprint planning session.

Step 2 – Ensure we get the PL committed

We schedule the meetings with the project lead to (a) confirm his availability and commitment, and (b) to allow project lead to review and revise the AGENDA.

For the sprint planning meeting invite we suggest a 60min slot, highlight the first line, apologise to the team as the planning meeting falls on a Friday, and propose an agenda.

Phase 3 – Invite the rest of the team

A week before the sprint planning session we invite the team, giving them the information of pre-requisite setup:

… and an overview of what to expect.

estimating and planning DEV-1

a la Lync poll (vsarDevOps)

The vsarDevOps team did not get the sprint planning pre-requisite email to the team in time, forcing us to do the first planning session using Lync polls.

We start by showing what needs to be estimated and providing a quick overview of each story by the project lead:

The ruck master walks the team through the estimations using a Lync poll, offering 0.5, 1, 2, 3, 5, 8 and 13+ as story point (SP) options.

Clear previous votes, paste the title of the story to be estimated in IM, set the option Results are hidden from attendees and time-box the vote.

We recommend that you pick the highest common value as a quick average, i.e. 3x3 SP, 4x5 SP and 1x8 SP would result in 5 SP. If you get a split you pick the higher (worst case) value, for example 4x3 SP and 4x5 SP would result in 5 SP.

NOTE: Remember to switch all team members to Lync Attendees, otherwise they will see all votes and probably be influenced.

a la TFS Agile Poker (vsarSecurity)

You need a WIT query that returns the stories to be estimated. In most cases a query looking for approved stories in your triage iteration path will be sufficient:

Using TFS Agile Poker gives you a better user experience. Users can select the story to be estimated to get more detail and the tool helps you pick the correct estimation average.

confidence vote

As part of the planning session, create a Lync poll to establish a confidence vote for the imminent sprint and the solution release overall.

Ask the attendees to vote at the end of the planning session to determine their confidence of “shipping” the solution as planned.
vsarDevOps team members, who were able to vote, showed great confidence with an 4.625/5 average.

gearing up for R-R and DEV-1

Agreeing on ONE innovation for the team going forward and selecting the stories for the next sprint are typically done during the sprint planning session and optionally refined (pruned) thereafter.

ONE innovation

As a team agree on at least one or more innovations for the team to consider for the next sprint. Examples from recent retrospectives include include:

Complete development a week before the next sprint ends, giving us a few days to stabilise the deliverables.
Perform the planning and estimations using TFS Agile Poker, instead of Lync Poll, to improve team experience.

“gang up” and select stories

Based on our part-time and distributed teams, we can deliver roughly 3 story points per contributor/developer and reviewer/tester in a one-month sprint.

This means that the recommended maximum work to grab for the next sprint is a total of 12 story points. Work with the project lead and product owner to prioritise the backlog and grab the first do’able stories for the first DEV-1 sprint.

Last, but not least, notify the team and ensure everyone knows what’s next.

what’s supposed to happen next?

Commit to stories, which will include the developer/contributor and tester/reviewer pairs.
Host the weekly 15+15min stand-up meetings.
Go, go, go with the DEV-1 sprint.

Now it’s time brief the other ruck masters in the ruck-of-ruck meeting and to kick the development sprint tyres. See you in the next journal Smile