ALM Rangers Ruck – Proposed innovations to the v1.2 guidance. Thoughts?

We introduced the concept of “loose Scrum” (also known as a maul or ruck in Rugby) in 2011 to streamline the ALM Rangers projects and continuously adjust and improve to maximise respect for people, optimise development flow and embrace the philosophy of kaizen (

Revised 2014-02-11.

remembering our constraints

Before we cover our observations and proposed innovations it is important that you peruse ALM Guidance: Visual Studio ALM Rangers — Reflections on Virtual Teams and Things you probably [did not] know about the Visual Studio ALM Rangers to understand our world, challenges and constraints. One of the self-inflicted (intentional) constraints is our 24x7 dog-fooding of VS Online and using features out-of-the-box.

We are in the process of wrapping up our last in-flight projects and preparing new teams to take-off on new adventures. As part of kaizen we have made observations and are discussing possible innovations herein.

so, where’s the fire … what are my observations?

Teams have agreed on very ambitious estimations, often adding 8h and even 40h tasks to their sprint backlog. Failure to deliver working solutions at the end of sprints and a trend to “carry over” work to next sprint. image
Teams often fail to invest the time to plan each sprint or perform micro-task planning. Inaccurate planning, inconsistent sprint velocities and overhead in terms of task management during the sprint.  
Teams are seldom doing sprint retrospective, or giving candid feedback. Retros are seen as a process overhead, rather than opportunity to improve the team environment.  
Teams often start with an objective to complete in 2-3 months, but continue from sprint to sprint until work is eventually completed. The team has no milestones to work towards and no horizon in sight. Projects turn into an on-going rut Sad smile  
Teams often start energetic, then deflate and awaken towards the end for the usual death march to meet expectations, or Rangers simply wait for the last possible moment to deliver. Frustrations amongst team members, especially where there are dependencies, and a frequent cancellation of features. Also a spike (burn up) during a sprint as unknown dependencies are identified “late” as shown. image


proposed innovations

Many of the proposed innovations are based on learning's from Scaled Agile Framework® (SAFe™), which is an approach we are investigating as part of our Agile and Ruck environments.


Light bulb #1 - normali[s|z]ed estimations

Simplify estimation effort, improve estimation accuracy and ensure estimates are done and supported by team.

image See How do you normalise your velocity estimation for more information.

  1. Estimate assuming full-time availability of resources.
  2. Team estimates stories using story points based on developer/contributor and a tester/reviewer pair per story.
  3. Team finds smallest story that can be developed and validated in full day, relating it to one story point.
  4. Team estimates the remaining tasks, using the 1 story point task as a reference.
  5. Split up big stories into smaller stories that are equal or less to the part-time sprint maximum.
  6. Visually indicate when a story/task is ready for testing/review. For example, the snippet shows a feature #9462, with a story #9463 that has been developed and tagged as ready for testing.
  7. A story is only complete when development and testing activities are completed, and the definition of done (DoD) is met.
    2014-02-11 …dev + test is not a waterfall sequence. Unit tests and test cases can be created before or in parallel to development efforts.
  8. The tester/reviewer should be a motivation for the developer/contributor to  avoid the last minute submission.

Clarification from discussions:

  • We will use the poll feature in Lync as a bare minimum or online planning poker solutions. Requirement is that at least 50% of the team is present and that the PO does no estimating.
    image … 1,2,3,5,8,13,21
  • Story points have no direct correlation with time (hours) and usually we calculate:
    ~days = days per iteration * (backlog size / velocity)
    However, as
    we have not been able to define an average velocity for Rangers, I propose we use the hybrid story point approach and associate our story point to a day, for example, which of these piles can I develop and test in a day? That’s 1SP and that defines the base of the estimations.
  • A story with a SP of 1, 2, 3, 5, 8 or more could be do’able in a day as well. It is all relative and based on the smallest pile of stuff the team identified as a SP=1.

Light bulb #2 - enforce a TRP sprint

Introduce pro-active sprint planning, reduce ambiguity and task management.


Each new project or subsequent release starts with a training-research-planning (TRP) sprint to gather the following objectives:

  • Motivation which outlines why we are considering the project
  • Vision which describes the objectives of the project
  • Smart objectives (specific, measurable, achievable, realistic and time-based)
  • Acceptance criteria which define what it take for the product owner(PO) to signoff the project
  • Definition of Done for the TRP sprint

The TRP sprints starts with a kick-off meeting, followed by research, training and finally a sprint planning meeting that plans the first construction sprint with a high-level of confidence and subsequent sprints with best-case estimates.

Light bulb #3 - enforce PSI time box

Ensure that the team has a realistic horizon in sight. Do less, better and ship what we have on demand.


In the context of Ranger solutions each release is time-boxed within one TRP sprint (see above), 1-3 development sprints and a QP sprint (see below). Each project team is divided into one or two feature teams, each with its own sprint plan, but all sharing the same cadence and project vision, objectives and acceptance criteria.

Each feature team commits time at the end of the sprint to do a sprint retrospective and plan the next sprint. In addition each team delivers a 1-3min video which summarises the sprint deliverable and can be used as reference for new team members or stakeholders. This becomes invaluable evidence for the Ruck-of-Rucks! See for an exceptional example of a sprint demo video.

Clarification from discussions:

  • The idea is that we make it easy for a team to deliver evidence on their working solution and allow them to do some well-deserved PR.
  • Essentially I see the following standard story for each sprint:
    Standard: As a stakeholder I can view a sprint demo video so that that I can get a quick overview of deliverables  

Light bulb #4 - enforce a QP sprint

Raise quality bar across the board


Scaled Agile Framework® (SAFe™) introduced a hardening-innovation-planning (HIP) sprint at the end of a potentially shippable increment (PSI).

We will us the opportunity to raise the overall quality bar and plan during this last sprint. The team focuses on eliminating any remaining debt, such as copy-editing, and validates that all quality bars have been met and encourages the product owner (PO) to signoff. In addition the team uses the time to experiment with innovations for future releases and if needed, to plan the next release.

Light bulb #5 - agree on one innovation

Minimise waste of time due to meetings and encourage continuous improvement.

Instead of meeting to discuss what went well, what went not so well and how we can improve, we agree on at least one innovation for the next sprint.  This becomes invaluable evidence for the Ruck-of-Rucks!

Clarification from discussions:

  • The idea is that we continue to discuss and agree on what went well and badly if possible, but that each team must deliver one innovation for the next sprint.
  • Essentially I see the following standard story for each sprint:
    Standard: As a team we can define one innovation for the next sprint so that we can improve our project continuously  

Light bulb #6 - revise ruck chart

Create consistent project plan and align with visualization such as the Scaled Agile Framework.

Retire our v1.2 Ruck Cheat Sheet …

… and introduce a new poster / cheat sheet …
Ruck Cheatsheet 

we need your thoughts and consensus

We need your thoughts and candid feedback, so that we can make decisions by consensus and start the dog-fooding of innovations with our next project adventures.

Add your comments below or contact us by email.

Comments (23)

  1. Leonard Woody says:

    Hi Willy,

    I like this.  It mostly makes sense given our particular constraints and I'm eager to try it on the next Rangers project!  Especially like the normalized estimation concept, TRP sprint, and video sprint review!

    – Woody

  2. Tim Star says:

    Section 1 – I am not following all of the math and logic.  In my day job I encourage teams to avoid adding stories with points 13 or greater (this indicates the story is too large or too many unknowns).  I don't even want to see more than a single 8 point story in a sprint but allowing an 8 recognizes that some tasks are just big and easier to tackle at that size than it is to break it down into smaller stories.  If a team fails to deliver on a committed item with 1 to even 8 points it tends not to be that big of deal from a velocity perspective.  The sweet spot for me is around 3 points – I like to see a bunch of 3 point stories in a sprint.  The problem I have with the scaling proposal as I understand it is we seem to be taking the smallest possible number in our story point scale, a 1, as a reference story which does not allow us to estimate the story that might equate to a 1/2 day story.  I would rather see the reference story equate to a 3.  I also don't follow how 1 point is a full time dev/rev pair and 3 points is  the maximum points the dev/rev pair can achieve in a month.  That suggests each team member can commit 24 hours to a project in a month, about 6 hours per week. While I do see some rangers spending 5+ hours per week on work for the team, I also see a measurable number of team members (perhaps even most) spending much less time and often dropping off of the team all together.  I think we should target 2 – 3 hours per week per team member or 8 – 12 hours a month as a team members capacity.   Finally, should we be trying to tie points to hours?  

    Section 3 – I am lukewarm on the notion of having teams within the team.  Normally I would want the entire team focused on the overall success of the sprint.  More than one team could promote a focus on feature team deliverables which could lead to a successful feature delivery but an overall failure of the team.  

    Everything else looks good.

  3. Willy-Peter Schaub says:

    @Tim, I agree on the story points and for ALM Rangers I am looking at 3 being the "preferred" maximum and 5 being the "tolerated" maximum, viewed with suspicion. This is primarily due to us working part-time, which makes longer running tasks or "bigger piles of stuff" too risky.

    No need to worry about the maths, because it will be an evolving adventure … I just tried to associate the time-less story points with a rough estimate of time within a Rangers context … then again this will vary with each team.

    Assumption 1: 1SP defines a pile of stuff can be completed in a day.

    Assumption 2: We have 260 working days per year, which works out to 21.67 working days per month or roughly 21.67 of the 1SP stories.

    Assumption 3: A Ranger can commit 1/8th of a calendar month to Rangers projects, which works out to <1h/day or roughly 2.708 of 1SPs/month.

    Now I need to emphasise that 2 or 3 SPs may also be do'able in a day, but I am assuming they will take more.

  4. Max says:

    Hi all,

    where can i get a new a new poster / cheat sheet in a better quality to print out?

  5. @Max, the old poster can be found on The new cheat sheet will be released with the next update of the Ruck guide if accepted.

  6. I really like this =), can't wait to start using it

  7. Tommy Sundling says:

    I think it looks good. The part I see as a potential challenge is the video review. While I like the idea behind it I'm not sure how well this will work in practice with our distributed teams. My initial reaction was that this practice is best suited for co-located teams, but I'd happily be proven wrong! 🙂

  8. @Tommy, the alternative to the video is to have a sprint review meeting, which includes a the demo. While this is ideal, it has proven *very* challenging to schedule consistently. The idea of the demo video is that it can be done anytime towards the sprint by one of more, reviewed by all in the team and dropped in a share for other teams to review. I would be interested to understand why you feel it is not suited for distributed teams?

  9. niel zeeman says:

    Scheduling meetings can be a pain, but creating and editing a video as well. It is a very difficult thing to do, especially in a distributed collaborative fashion.

    What worked very well for us was using  wiki of sorts. A couple of screen shorts and some commenting. Much more "collaborative" friendly, and frankly quicker than setting up a video IMO.

  10. @Niel, when we talk about videos it is not asking for the quality delivered by RobertM 🙂 Setting up a Lync session, running a review session on your own or preferably with a few colleagues from the team and hitting the record button results in an invaluable video.

  11. Osmar Landin says:

    Overall I quite liked the suggestions but I have some concerns.

    #1 – normali[s|z]ed estimations

    – "The tester/reviewer should be a motivation for the developer/contributor to  avoid the last minute submission"

    This will not prevent developers submiting their work in the last minute. The review/test task should be planned as well development tasks.

    – "We will use the poll feature in Lync as a bare minimum or online planning poker solutions. Requirement is that at least 50% of the team is present and that the PO does no estimating."

    Is Lync the best tool for that? I work at customers' environment all day and usually I don't have full internet access so Lync can be a problem in my case.

    #3 – enforce PSI time box

    "Each team delivers a 1-3min video which summarises the sprint deliverable and can be used as reference for new team members or stakeholders"

    I agree with @Niel. How this will work? Who will be responsible for creating this video? This is not a trivial task and may impact the delivery of the current sprint as well as the planning for the next sprint.

  12. @Osmar,

    #1 – Pairing will hopefully improve collaboration and visibility into progress or lack thereof. It is up to the tester to raise an impediment of the progress is lacking.

    #2 – We are currently looking at using Lync Poll feature and the TFS Agile Poker application for the Rangers. Lync is a light-weight poll solution and should be well suited for Ranger teams which use Lync for collaboration.

    #3 – If I compare the effort of producing a 2-3 min video using Camtasia, Lync or any other tool, with the effort of getting the entire distributed team together for a sprint review and demo meeting, I vote for the former. The responsibility of producing the video is with the team and there is always one in the team that knows and enjoys the "fun" of producing a demo video.

  13. @Rangers, THANK YOU for the ongoing and candid feedback, which helps us better understand the challenges 🙂 Keep the candid and invaluable feedback rolling in!

  14. Hamid Shahid says:


    Looks really good, especially normalized of estimation and TRP Sprint. Would one of the outcomes of such sprints be a more detailed task list?

  15. Eric Golpe says:

    OK, well you did ask for uncandid feedback, and the quintessential New Yorker in me will come forth:

    #1 Normalized Estimations:  Not so familiar with the SAFE abridged estimation methods, but with care I can see this may be feasible. Although, admittedly I look at it as a ratio and proportion approach with some capping, so let me explain:  I've been estimating activities while building out a backlog based on story points where everyone throws in a card. (Standard Planning Poker, which has been prevalent with story point estimation for years).   I have a couple scrum decks I even use: one with Fibonacci numbers, one with “2 power values” (0,2,4,8,16,32,64), and a few other variations.   I like the 2-power values because I can assign bitwise operators directly and figure out all possible combinations during estimation, and group only those – rather than take the highest/lowest estimations.   That helps me substitute tasks when normalizing my backlogs for resourcing and such.   Anyway, the point here is you could use a regular playing card deck, it really doesn't matter.  The end result is an estimation that leaves you with the most accurate effort estimates. (See…/Software_development_effort_estimation ).

    While the Wikipedia article on effort estimation lists only psychological factors, I’d say there are actually multiple factors that influence estimation: ie: perceptions, knowledge, resource availability, etc. that may produce inaccurate estimates, in addition to the psychological factors.   Without enough objective data to go with the subjective plans, effort estimates will always skew larger.  So for me, I think understanding HOW the normalized estimations contribute to a more accurate, ALM Rangers project-context is the info I’m missing here.  So that brings me to #2, enforcement of a TRP sprint:

  16. Eric Golpe says:

    #2 Enforcement of a TRP sprint: While I'll admit this sounds quite Nirvana-esqe (my new buzzword of the week), it's a costly proposition for a scrum sprint with little value to the business in the short term, but huge value over the long term and potentially the project itself.  This could impact the perception/realization of a condensed go-to-market period within the overall plan.  (Hence, the core value of Agile: getting releases out to the consumer at record speeds.)  You sort of give this up as at the end of TRP, you have no working software to show. (Or do you?)  However, in estimation of Ranger projects with net-new or uncharted epics and tasks, it could be very valuable to increase estimation accuracy, and enhance planning activities. However, it likely will have little effect to disambiguate tasks unless research and materials are readily available and easily understood.  Many Rangers projects deal with cutting (and at times, bleeding) edge technology, where implementations are not yet well known, but need to be proven out.  In such cases, SMART goals, delivery acceptance criteria and definition of done is not well understood to begin with.  These TRP materials tend to form as sprints are realized, and projects normalize.  So, with that, do you move kick-off planning and story point estimation to beyond the TRP sprint, in order to produce higher quality normalized estimations?  Do we formalize the Vision / Scope to be more waterfall in methodology, versus a pure-agile approach that can tolerate Vision and motivational changes?

    #3 I agree, enforcement of milestones and incremental progress is a key gating factor, and can ensure the backlog is progressing with the appropriate burndown.   However, now that TRP is part of the cycle, if the estimation/TRP wasn't properly invested in prior to the establishment of milestones, and estimates don't reflect the true "critical path", (due lack of knowledge, vision, resource availability, scoping, etc.) the milestones may be incorrectly defined from the start.  The Scaled Agile Framework (SAFE) further acknowledges a reasonable understanding of lean and agile needs to be in place, as well as knowledge of the productive capacity (velocity available for new development) across all release trains. (Refer to Architectural Kanban: )  The SAFE collaborators themselves guide toward driving collaboration, and providing WIP limits so teams do not create implementations or timeframes that far exceed capacity and reality. The sprint retrospective and video proposals certainly fit the collaborative side here.  I think what may be lacking is guidance on "critical paths" and burndown analysis, in an easy framework approach, so you can walk into the next sprint with improvements.  Which leads us to hardening-innovation-planning (HIP) sprint and the agreement on one innovation.

  17. Eric Golpe says:

    #4 & #5:  Hardening-innovation-planning (HIP) sprint and the agreement on one innovation: The core principle I see to keep sights of here is to continue the Kaizen lifecycle (Plan, Do, Check and Act accordingly) as well as the Ruck principles at play.  I see this as the perfect retrospective area, although nothing has been released during the HIP sprint, which again may have negative impact of the time-to-market, and a residual effect of increased cost.  Do you stage deployment at this point, and move final quality gate checks to this final sprint?  #6 Ruck Chart Updating, will likely be a product of an intersecting union across all projects’ HIP innovations (ie: the lessons learned and project vectoring).  What epics can Ranger’s contribute to the v1.2 guidance as innovations, based on our thoughts here?  

    A big thank you to all for contemplating my feedback too.

  18. @Eric, I will answer as best and candidly as possible and let you push back!

    #2 … I like Nirvana-es and yes, it is in contradiction with business value and going to market quickly. It is also not intended for all projects and it is up to the team to do ½ sprint TRP or an entire sprint TRP, whereby our sprints are calendar months. If we are talking about cutting edge (always bleeding) technology projects we would typically restrict the TRP to information sharing (training) by the product owner and planning. If, however, we are working on an established project, i.e. Version Control Guide, the TRP would be mostly focused on what we can and should be doing (research) and planning the DEV sprints. The TRP may viewed as a “splinter” by the Agile community, however, we have found that many Ranger projects have struggled due to a lack of up-front planning and definition of clear objectives, which are key when working with distributed, disconnected and part-time resources, with no committed team resource bandwidth.

    #3 … it is important to highlight that we are cherry-picking SAFe concepts and are not going to be SAFe compliant … not possible in our environment. Every sprint planning includes a backlog and objectives grooming, with the option of a reset. If we are off-track we either align or reset in future. We are hoping that the TRP sprint, normalized estimations and objectives will ensure we do less, better and split a project in multiple versions (PSIs), rather than trying to do it all in one. I will let the Treasure Map team jump onto this thread, however, just by looking at the backlog, trying to size the “pile of stuff” and estimate what can be done we have realized at the start that one version will not be enough. While the business may not like this, I *love* it, because we can now ensure the team is not stressed out and in a position to deliver quality … which will eventually change the business perception (I hope). Burn down analysis will follow once we have done a few sprints … if you look at our collection of burn downs you will realise that we have a wide range of interesting burn down(across/up) charts that are screaming for normalisation.

    to be continued …

  19. … continued.

    #4/5 – We never really have the time to harden our solution, to learn from our mistakes and to innovate … hence the enforced HIP sprint. The intent is to ask the developers to sit on their hands or engage on another project, while we work on quality validation, reviews, bug resolutions and learning from our mistakes and properly planning the next version (PSI) or deferring to the next triage. It is intended to embrace Kaizen principles and to deliver the quality in our “less but higher quality” mantra. It will be up to our Ruck Masters to take the sprint innovations and learnings to the Ruck of Rucks, revising our suggested innovations and the Ruck Guide accordingly.

    What innovations can a Ranger contribute to Ruck vNext? – Anything … this thread of comments will be giving the Ruck Masters a few sleepless nights and the feedback to discuss and revise the Ruck guidance. You can either add more thoughts to this thread, or BrianB and I direct.

    Hope I answered all your questions, if not “shout”.

  20. Tommy Sundling says:

    @Willy: The potential challenge I see with the video isn't technical, but with what I read as unclear responsibility of who is responsible for making sure it happens (the Feature Team, yes, but this is potentially too ambiguous if no one steps up and risk falling between the cracks). If we would make it the responsibility of the Feature Lead, who can then delegate the task if someone else wants it, this would in my mind make the process 'cleaner' and increase the odds of the video happening consistently.

  21. Alan Correa Morais says:

    Nice, I really liked the method.

  22. @Tommy, good point.

    The responsibility for defining the sprint pre-requisites and delivering the sprint nuggets lies with the TEAM. They need to own the sprint, be passionate about the project and be motivated to deliver a working solution… if not, we have a "stop the bus" scenario.

    To ensure the team understands the current and suggested innovations we rely heavily on the Ruck Master (RM) who mentors the team. Not sure if you noticed, but the Ruck Master takes the sprint deliverables to the Ruck-of-Ruck gathering. RMs are therefore encouraged to motivate the TEAM to deliver the sprint deliverables 🙂

  23. Brian Blackman says:

    The point of improving estimation is to better know if we know what we need to do. Large story points or remaining work tells me you don't have a clear understanding of the work at hand. I like small since to me it means we either know what needs to be done or variance will be less impactful than with large.

    Getting improvements from retros (still prefer postmortem 🙂 ) is a challenge. If we can just get one improvement after each sprint (not necessarily from each team) then I would be happy knowing we are trying to get better.

    The use of video works well with our community since we are global. I would love to hear what other open source projects are doing in regard to Sprint Reviews.

Skip to main content