Efficiency Order vs. Value Order

I’ve been meaning to write a comparison of Waterfall and Agile software development, as well as the truths in the PMBOK. Until then, I just want to point out one key difference: efficiency order vs. value order.

This is my own terminology, but “efficiency order” and “value order” seem to be the two most reasonable responses to the question, “In what order will work be performed?” Work can be ordered according to the value generated, such that the highest priority work is accomplished first. Or work can be ordered according to the sequence with the least waste. Value order puts building a submarine hull before installing sonar, since submariners can live without sonar, but not without a hull. Efficiency order might install sonar before the hull is complete if doing so requires less labor and improves the schedule. Continue reading “Efficiency Order vs. Value Order”

Efficiency Order vs. Value Order

Team Charter – DC SUG – “Are We Done Yet?”

I attended the “Are We Done Yet?” meetup of the DC Scrum Users Group last night. @RichardKCheng did a good job as the trainer. His slides are available as a PDF.

The Team Charter is the team’s self-realized, self-authored norms for how they work, unlike the Project Charter that is handed down from on-high. This includes things like the schedule, definition of done, project understanding, and team rules. There’s no reason I can’t write one up for our team tomorrow.

Some of the stories told and questions ask definitely point to other teams needing a Team Charter more than my team does. We’re already on board with timeliness and professionalism, and we have a decent Definition of Done. Even so, it certainly won’t hurt. Rules for ending horseplay, being available during core hours, and paying attention during meetings are only necessary where the team doesn’t already do these things.

For the “Definition of Done” and “Definition of Ready” themselves, Richard spoke to defining these at various levels:

  1. Ready to Start
  2. Project Backlog Item (PBI)
  3. Sprint
  4. Release

The “Definition of Ready” is essentially the “Definition of Done” for “Getting a User Story/Requirement Ready.” The backlog should be prioritized and refined before Sprint Planning occurs so that there is a supply of PBIs that are Ready. Richard recommended having a refinement meeting several days before Sprint Planning and then having a developer review the PBIs help get to this Ready state.

One of the key recommendations of the night, which should be obvious once you understand the principles of short feedback loops is that the more things you put off doing until the Release level, the greater your risk of failure. As much as you can while being efficient, move activities from the Release level to the Sprint level, and from the Sprint level to the PBI level.

Maybe security scans are onerous and time-consuming, but there could be ways of running part of the scan every Sprint, which thus gives the team the opportunity to address the findings much earlier.

While multiple weeks of regression testing can’t, by definition, be performed every two weeks, creating automated tests (i.e. Coded UI Tests) can permit you to get much of the value at the Sprint or even the PBI level. Why not run the automated tests after every check-in?

All in all, a good meetup, but mostly a confirmation of what I suspected.

Team Charter – DC SUG – “Are We Done Yet?”

My team’s Definition of Done

Our “Definition of Done” should have been written up long ago. While my team may act as the model “Agile” team in our company, we certainly have a long way to go.

The following is our first good draft of our “Definition of Done,” and a lot of it is about how we use Team Foundation Server (TFS), rather than productive activities that go along with the steps.

Without further ado, I present for your edification or amusement, one team’s

Definition of Done


  • Proposed (set to Active)
    • The Requirements Review Checklist has been answered.
    • The Area Path, Iteration Path, and Release Version are accurate.
    • The Requirement has been committed to a sprint.
    • The CCB CR Number and Size are populated.
    • Not Blocked (Blocked set to “No”)
    • At least one child Task has been created.
  • Active (set to Resolved)
    • The requirement has been met.
    • All child Tasks and Bugs are Resolved or Closed.
  • Resolved (set to Closed)
    • Verified that the bug requirement has been met.
    • Test Scripts/Test Plan has been updated if applicable.
    • Wiki documentation has been updated if applicable.
    • Feature documentation has been updated.


  • Active (set to Resolved)
    • All child Tasks are Resolved or Closed.
    • View the parent Requirement to determine if this is the last child to be resolved (in order to then resolve the parent).
    • The Root Cause is set to the appropriate value (not “Unknown”).
    • The Reason is set to the appropriate value (“Fixed” unless Path 3 below).
    • The Area Path, Iteration Path, and Release Version are accurate.
    • The Bug has been addressed:
      • Path 1: Bug has been fixed in the data or environment and no longer occurs.
      • Path 2: Bug has been fixed in the code and will not occur after a new build (nightly).
      • Path 3: Bug cannot be reproduced, needs more detail, or reports as-designed functionality.
  • Resolved (set to Closed)
    • Verified that the bug has been addressed.
    • Test Scripts/Test Plan has been updated if applicable.


  • Proposed (set to Active)
    • Remaining Work has been set according to the Size of the parent requirement and/or the developer’s estimate.
  • Active (set to Resolved)
    • Task is accomplished.
    • Remaining Work is 0 and Completed Work accurately represents the hours spent on the Task.
    • The Area Path, Iteration Path, and Release Version are accurate.
    • View the parent Bug or Requirement to determine if this is the last child to be resolved (in order to then resolve the parent).
  • Resolved (set to Closed)
    • Unit Tests are updated.
    • Code Review is completed.


  • Sprint Retrospective
  • Team Sprint Review
  • Internal Sprint Review (cross-team functionality)
  • “Sprint Review and Approvals” form drafted.
  • Customer Sprint Review and “Sprint Review and Approvals” form signed.
  • The Release Version of all completed CRs populated.
  • Release Notes draft updated.
  • The Coded UI Tests (CUIT) pass.


  • Regression Testing complete.
  • All Change Requests in the release are Closed (in cooperation with the Change Management team).
  • All Requirements and Bugs in the release are Closed.
  • All documentation included in the release package submitted (Change Management Team checklist).
  • Informational meeting and notes provided to the Help Desk, Documentation Team, and Trainers.
My team’s Definition of Done

The Current Iteration in TFS

I’ve wanted to write queries based on the current sprint in TFS (Team Foundation Server), as have quite a few others, including one developer at my office yesterday.

Looks like Microsoft listened. @CurrentIteration is being added as a token.

That’s great, of course. When looking to write a query against the current sprint, however, you are in danger of losing sight of unclosed work items in previous sprints. When you reach for @CurrentIteration, you probably just mean “all unfinished work that has been committed to a sprint.” If you filter to a single sprint, you’ll miss any stragglers you failed to close or move forward from previous sprints.

Consider using the following pattern, where “ScrumOfScrumsRelease” is your backlog path, and all of your sprint paths are children to that:

Under backlog iteration node, but not equal to the backlog iteration node. Not closed.
Under backlog iteration node, but not equal to the backlog iteration node. Also not Closed.

This will also catch any items that weren’t closed in your previous sprints.

The Current Iteration in TFS