ALM Rangers ALM Dogfooding, Ruck and the new TLAs – Part 5

Article
11/11/2012

Continuing from ALM Rangers ALM Dogfooding and the age of the visual board – Part 4 we will focus on the Ruck backlog in this post, sharing experiences, asking for candid feedback and giving the ALM Ranger project leads a checklist to work with.

IMPORTANT: Always refer to the ALM Rangers Practical Ruck Training and Reference Manual document for the latest Ruck guidelines. These blog posts are only intended as gap-fillers when we encounter challenges as part of our dog fooding or questions that deserve a bit more elaboration.

UNDER CONSTRUCTION WARNING … we are posting this early DRAFT to get your feedback and allow the Ruck Masters to request refinements and tweak the content. I will remove this warning as soon as the dust has settled.

Last updated on 2012/11/10

Recap … what is Ruck and why are we using it?

The ALM Guidance: Visual Studio ALM Rangers — Reflections on Virtual Teams article is a good reflection of where Ruck came from and why we are continuously evolving Ruck. We like to refer to Ruck as the “Practitioners Scrum Variant”, catering for a team environment in which all team members are part-time volunteers, with a real job and a family. The latter obviously receives the most focus and priority, leaving only fragments of capacity to Ranger projects. This combined with the geographically dispersed team members and numerous time zones is creating a challenging backlog planning and sprint management environment.

What are some of the major variations between Ruck and Scrum in a nutshell?

Scrum https://en.wikipedia.org/wiki/Scrum_(development)	Ruck https://blogs.msdn.com/b/willy-peter_schaub/archive/tags/ruck
15min Daily Scrum Meeting with team eye:eye	15min (bi-)weekly stand-up meeting, with an optional 15min free-for-all chat thereafter with team vEye:vEye
8 hour Sprint Planning Meeting with team Entire Team (product backlog) Dev Team (sprint backlog)	Project Lead and Program Manager \| Ruck Master plan meet for ½ hour to define and propose a product backlog prioritization and suggested sprint plan. Entire team grooms the backlog offline, collaborating by email. The sprint backlog is discussed at the last or first stand-up in each sprint.
4 hour Sprint Review Meeting with team	Teams produce videos of their deliverables, which are distributed to all stakeholders
3 hour Retrospective Meeting with team	Team submits their retrospective feedback during the last week. Project Lead and Program Manager \| Ruck Master plan aggregate results, which are discussed at the next stand-up during optional time slot

Time where the entire team can be together in a video conference meeting is precious and therefore we have to revert to offline collaboration and primarily email when planning, estimating and stack ranking.

Backlog planning terminology

The terminologies are documented in numerous publications, yet many of us (myself included) often wonder what the difference between the tsunami of terms is. Do you know what the difference is between a scenario, an Epic, an MMF and an MVP? I love (joke) acronyms, because in this context MVP stands for “Minimum Viable Product”, not Microsoft Most Valuable Professional as most of us are used to.

To be honest, I have to keep notes and often fall back to our quick reference posters and cheat sheets for a quick terminology rescue.

Let’s focus on the backlog planning, the various terminology and guidelines we are following in Ruck. We are trying our utmost to align with the rest of the communities and processes, but are trying to keep it simple!

Let’s start with the following illustration…

We are now sharing common sprints, which are simply a year sliced up into 2-week or 1-month sprints / iterations. While not all projects start at the same time, the common sprint model synchronises the beginning and end of sprint ceremonies across all our projects and simplifies the overall tracking and administration efforts dramatically.

For projects that span many months, typically strategic initiatives, we may define Pillars. These relate to strategic objectives, for example Improve the Ruck Ecosystem or Introduce New Deliverable Experience, and are essentially bigger buckets for Epics.

For most projects we slice and dice features into Epics –> Product Backlog Items (PBIs) -> Tasks, whereby a PBI is used to define a collection of other PBIs, a User Story, a Test Case or a Minimum Marketable Feature (MMF).

Epic – group of related PBIs.
User Story - communicates functionality that is of value to the end user of the product or system.
MMF – feature with a clearly defined user story in the form of “As a <user type> I want to <do some action> so that <desired result>", which represents a marketable and shippable feature.
Task – tasks needed to implement an PBI and meeting its acceptance criteria
Test Case - test and project managers to track the testing efforts in context with various requirements, features and other logical conditions

Backlog planning “Ruck” guidelines | checklist

The following table is for our project leads, program managers and Ruck Masters and summarises the backlog planning guidelines.

Artefact	Intended usage	Constraints	Recommendations
Pillar	Collection of Epics that span across many sprints, such as strategic FY13 Epics.	Define only Epics as children of a Pillar. Pillar is assigned to a major node such as iteration ALM/FY13 and never assigned to more granular sprints.	Only use for strategic projects that span many (>10) sprints.
Epic	Collection of related PBIs. The Epic typically defines the value proposition for our solution and is used by Bijan when he runs into the VP in the hallway.	Each Epic must have a detailed description and acceptance criteria. Epic and state thereof is owned by the Product Owner (PO). Epic is assigned to a major node such as iteration ALM/FY13 and never assigned to more granular sprints.	Define only PBIs as children of an Epic. Do not schedule Epics unless approved by PO.
PBI	Collection of tasks which clearly defines the user story for typically one persona in the context of a potentially shippable feature.	Each PBI must have a detailed description and acceptance criteria. PBI and state thereof is owned by the Project Lead (PL). PBI must be assigned to a sprint that appears in your backlog view as iterations available for planning, i.e. ALM/FY13/Sprint5, before tasks within are worked on. An exception is a PBI that acts as a container to other PBI’s that may span multiple sprints. In this case the PBI is assigned to a major node such as iteration ALM/FY13 and never assigned to more granular sprints.	Do not span PBI’s across sprint boundaries. Do not schedule PBIs unless committed by PL.
Task	Autonomous activity of work that can involve activities such as construction or testing or review or documentation.	Task and state thereof is owned by the team member. A task must be assigned to a sprint that appears in your backlog view as iterations available for planning, i.e. ALM/FY13/Sprint5	Do not define tasks that are greater than 8h, preferably defining a maximum remaining work of 4h or less.

Review using illustrations

	Healthy backlog view for a strategic project that spans more than 10 months. The dotted red lines indicate the sprint barriers for sprints that appears in your backlog view as iterations available for planning. Shows a pillar, containing two Epics, five PBIs and two tasks. PBI 2 contains Task 1 and Task 2, and has been assigned to a sprint. PBI 3 contains PBI 4 and PBI 5 and has been assigned to the next sprint. Typically PBI 1, PBI 4 and PBI 5 will contain more Tasks.
	Healthy backlog view for a project that spans a few weeks or months. The dotted red line indicates the sprint barrier for sprints that appear in your backlog view as iterations available for planning. Shows one Epic, two PBIs and three tasks. PBI 1 contains Task 1 and Task 2, and has been assigned to a sprint. PBI 2 contains Task 3 and has been assigned to the next sprint.
	Unhealthy backlog view, because PBI 1 spans across two sprints. See below for one of the various possible resolutions.
	Healthybacklog resolving the previous unhealthy backlog. PBI 1 has been further sub-divided into PBI 3 and PBI 4. PBI 1 has not been assigned to a sprint that appears in your backlog view as iterations available for planning. PBI 3 contains Task 1 and has been assigned to a sprint. PBI 4 contains Task 2 and has been assigned to the next sprint. PBI 2 contains Task 3 and has been assigned to the next sprint.

Frequently Asked Questions

When I perform a review which tasks do I associate my check-in with?

You must associate your check-in with a valid and existing task. It is up to the team to decide on the preferred mechanism for review tasks, but we recommend the following:

For small, ad-hoc reviews, check-in using the task that defined the completed work that is being reviewed.

For more formal and larger reviews, create a review PBI and review tasks that define all review activities. Use these tasks for review check-ins.

If a task cannot be completed in a sprint, must I split the parent PBI before moving the task to the next sprint?

If the tasks are small and few in numbers, determine if the effort of splitting the PBI out-weighs the value. If effort far outweighs the value, move the tasks which effectively split the PBI across two sprints. Otherwise create a new child PBI, assign the incomplete tasks as children and move the set back to the backlog, available for planning.

TLAs (Two | Three Lettered Acronyms)

MMF	Minimum Marketable Feature. See https://en.wikipedia.org/wiki/Minimum_Marketable_Feature for more information.
MVP	Minimum Viable Product. See https://en.wikipedia.org/wiki/Minimum_viable_product for more information. Microsoft Most Valuable Professional. See https://mvp.microsoft.com/en-US/Pages/default.aspx for more information.
PL	Project Lead. See Practical Ruck Training and Reference Guide https://vsarguidance.codeplex.com/downloads/get/461175
PM	Program Manager. See Program Management – Are some of the ALM Rangers Symbiotic PM’s? and Project Lead. See Practical Ruck Training and Reference Guide https://vsarguidance.codeplex.com/downloads/get/461175
PO	Project Owner. See Practical Ruck Training and Reference Guide https://vsarguidance.codeplex.com/downloads/get/461175