Managing distributed, part-time and virtual teams – Part 4 … Sprint objectives and repetition rule!
We continue from Prioritization, Normali[s|z]ed estimations, Portfolio, flights, teams, epics and VSO, venturing in the objectives (why are we here) and the concept of repetition (until is becomes the norm) as we are dog-fooding.
our context
Remember that the ALM Rangers are geographically distributed, virtual and part-time volunteers, delivering an average of an eighth (1/8) of a month of bandwidth. In addition every Ranger adheres to the family>job>rangers mantra, which means that the 1/8 of bandwidth can evaporate without warning at the most inopportune time for a Ranger project. Previous posts covered the planning, normalization and prioritization of features to balance the challenging context. In this post we will take a sneak peek into the “development” phase of a project, focusing on setting objectives and repetition from project roadmap, down to sprint level.
objectives
The team commits to a sprint, based on resources, features and objectives negotiated with the stakeholders. At the end of each sprint, you plan the next steps and optionally refine the project roadmap, objectives, features and resourcing. After a refinement, the team re-commits and thereafter the trade-off triangle (resource, features, and roadmap) remains inert for the duration of the sprint.
The objectives are not a “big stick”, nor “marketing fluff”. The overall flight / project objectives chiselled on the team dashboard during the TRP sprint, are typically inherited as sprint objectives as a whole or selectively based on the selected stories for each sprint.
Example showing the mapping of project objectives to stories to a sprint:
The objectives reinforce the why you are doing the project, what needs to be done, who will be responsible for what and how confident the team is about succeeding. Ensure you display them on dashboards, in communication and at the start of each and every (repetition) stand-up to re-enforce them.
?.1 Do you use separate objectives for a project, release and sprint, or subsets as shown above?
?.2 How important are objectives in your context?
repetition
Irrespective of the length of the sprint, it is important to adopt a sprinting pattern that is natural to the team. Let’s consider what we would typically action if we need to make alterations to our home, fly a passenger plane across the Pacific or fly to moon Europa:
- Assume ownership of the sprint challenge as a team, for example, travel to moon Europa.
- Review and refine the objectives, requirements and the Features from the sprint backlog, for example, transfer W astronauts to the moon, collect X tons and Y types of samples and return to Terra within Z years. Verify that you understand the requirements, are in a position to meet the acceptance criteria and are in a position to proceed with none or manageable unknowns.
- Plan and design the sprint development journey.
- Develop the features to realize the requirements.
- Integrate, Test and Validate the features.
- Reflect on the sprint, identify improvements and plan the next actions.
- Demo and ship working solution(s).
The following illustration shows that the roadmap contains the seven mentioned actions and is broken down into one TRP (Training-Research-Planning), one or more DEV (*elopment) and one QP (Quality-Planning) sprint. These sprints each contain the same seven actions. Looking at one of the DEV sprints, you will notice that each story on the sprint backlog contains the same seven actions. Every iterative lifecycle has a beginning to which you transition from somewhere else and an end, from where you transition to somewhere else.
A repetitive pattern from roadmap (release) down to sprints:
Step 2 is pivotal to the Agile Requirements Management lifecycle. You no longer work with detailed design specifications, but rather “wish lists” encapsulated in Features and Stories. The team is responsible to elaborate the requirements for the overall solution in an iterative manner and probably evolve a detailed description and acceptance criteria while iterating through the stories within the sprints.
The Scrum/Ruck Master (RM), in collaboration with the Project Lead (PL) and Program Owner (PO) has the responsibility of mentoring and guiding the team through this iterative journey. The use of a basic checklist can further iterate through each sprint consistently:
- Align with PO expectations and understand the objectives and requirements.
- Review and re-prioritize backlog Features and/or Stories as requirements evolve.
- Verify that all Stories are associated with one parent Feature and all Features with one parent Epic (idea).
- Encourage the team to reflect, innovate and show-what-they-have-done with a sprint and release demo. Seeing is believing!
- Contain scope creep, otherwise the team cannot commit to a schedule or resources, especially within our context.
?.3 Do you use a pre-development and post-development sprint to focus your team and raise the quality bar ?
?.4 Do you feel TRP and QP sprints, as eluded to in these posts, are interesting, great, bad (evil) ? If yes, why?
reference information
More information n program managers, flight board and our VSO dog-fooding can be found in this section.
- Program Manager (PM)
- Flight Board
- VSO
- This series
- Part 1 - Normali[s|z]ed estimations
- Part 2 - Portfolio, flights, teams, epics and VSO
- Part 3 - Prioriti[s|z]ation of ideas, features and
?.5 Are these tours of how we work and use VSO of value to you?
Comments
- Anonymous
July 10, 2014
Helpful. Thanks (^_^)