Ballot Debris

Thoughts on Agile Management, Leadership and Software Engineering

Using the ‘Release’ Concept in Agile

clock January 18, 2010 11:42 by author Chad Albrecht

I’m spending quite a bit of time these days helping organizations implement Agile methodologies.  As such I hear the same set of questions and see the same set of issues over and over again.  One of the issues I see quite often is the “long sprint.”  To explain what I mean by this I’ll use a hypothetical conversation with a Team Lead new to Agile.


Team Lead: “How do you deal with the fact sprint planning and reviews take so long?”

Me: “How long is long?”

Team Lead: “Sometimes a week!”

Me: “How long are your sprints?”

Team Lead: “Usually 3-6 weeks.”

Me: “How did you determine that 3-6 weeks was a good length?”

Team Lead: “Because we couldn’t spend 2 weeks out of every month not coding!  We use longer Sprints to avoid spending so much time in review and planning.”


For those of you that are experienced in Agile, you should see a few problems here.  For now, let’s just focus on the “long sprint” concept.  The “long sprint” seems to manifest in organizations that are always sprinting.  First off, this is in direct conflict with the name sprint.  Sprints should be just that, a focused exertion of energy over a short period of time…2-3 weeks max.  So how do we solve our Team Lead’s issue with spending too much time in review and planning and not enough time writing code?  Enter the “Release.”

A Release is a means of building larger blocks of functionality in multiple Sprints. (usually 4-6)  Some Agile methodologies (XP) implement this concept directly, others do not. (Scrum)  There are many reasons to use the concept of a Release, a select few are:

  • Some features just might not fit into a two week Sprint.
  • Allow team to perform work in parallel to development.  In general team members can do work other than sitting in sprint review and planning sessions.  This is because these sessions are lighter weight and involve fewer people.  You simply review implemented sprint functionality ensuring it meets the needs of the stakeholder and grab the next chunk of the prioritized Product Backlog. (ok, a bit more than that, but you get the point) These two sessions should not take more than 3 days.
  • Reduce the overhead of delivering software to production every 2 weeks.
  • Reduce the information overload caused by releasing every 2 weeks.
  • Define a delivery pace more inline with that of the organization. (the rope in the Drum-Buffer-Rope of Throughput Accounting)

The next logical question is “Do we create a Release Backlog?”  I agree with Mike Cohn in this case and would say no.  I do however, use the concept of a Release Plan or Release Roadmap.  According to Mike a Release Plan contains:

  • Graph showing historical velocity.
  • Prioritized Product Backlog. (including some big user stories, "epics")
  • A predicted range of where we will finish. This should be either a date-range for a fixed-scope project or a functionality-range.
  • Personnel assumptions. (Team members and availability)
  • Velocity assumptions. ("we’ll go about half speed during December because of holidays and time off")

I would also add the following:

  • A Vision Statement.  (“We want to add the shopping cart functionality and connect it to PayPal”)
  • Estimated Release Value as I discuss here.

Using the concept of a Release in Agile organizations can be an extremely effective way to increase efficiency through the elimination of waste.  I will try to post more on this topic in the future.  As always, let me know your thoughts.

Further Reading:

Extreme Programming Release Planning:

Mike Cohn on Release Planning:

Mike Cohn on why there should not be a release backlog:

Kelly Waters on Release Planning:

Prioritizing SaaS Features

clock July 29, 2009 06:14 by author Chad Albrecht

I’ve talked about using your Value Proposition(VP) to rank features by dollar value here and using Ideal Days to estimate duration here.  Now let’s combine the two and look at total value based prioritization of features or PBI’s.  In essence what we are doing is giving the highest rank to features that will yield the most value in the least amount of time.(cost)  To calculate cost we will need some measure of cost per hour.  If you have the actual numbers, use them, if not here are some tools you can use.  Work hours in a year: 2080 Annual salary:  $50K=$24/hour  $100K=$48/hour.  Margin for overhead: 20-30%.  With these tools let’s assume that our team makes on average $90K annually.  This gives us $43 an hour.  Adding 25% we get about $54 an hour.  From here we can simply multiply our cost per hour by our Ideal Hours to get total cost per feature.  Subtract our total cost from our value (sales) and we get the profit per feature.   We then prioritize (rank) by profit.


Feature Rank % of total Value Estimate (Ideal Hours) Cost Profit
8 1 5% $ 4,902 2 $ 108 $ 4,794
9 1 5% $ 4,902 2 $ 108 $ 4,794
2 1 5% $ 4,902 4 $ 216 $ 4,686
1 1 5% $ 4,902 8 $ 432 $ 4,470
3 1 5% $ 4,902 8 $ 432 $ 4,470
6 1 5% $ 4,902 8 $ 432 $ 4,470
7 1 5% $ 4,902 8 $ 432 $ 4,470
11 1 5% $ 4,902 8 $ 432 $ 4,470
4 1 5% $ 4,902 16 $ 864 $ 4,038
5 1 5% $ 4,902 16 $ 864 $ 4,038
10 1 5% $ 4,902 16 $ 864 $ 4,038
12 1 5% $ 4,902 16 $ 864 $ 4,038
16 2 4% $ 3,922 4 $ 216 $ 3,706
17 2 4% $ 3,922 4 $ 216 $ 3,706
13 2 4% $ 3,922 8 $ 432 $ 3,490
14 2 4% $ 3,922 8 $ 432 $ 3,490
15 2 4% $ 3,922 8 $ 432 $ 3,490
21 3 3% $ 2,941 2 $ 108 $ 2,833
22 3 3% $ 2,941 2 $ 108 $ 2,833
18 3 3% $ 2,941 4 $ 216 $ 2,725
23 3 3% $ 2,941 4 $ 216 $ 2,725
19 3 3% $ 2,941 16 $ 864 $ 2,077
20 3 3% $ 2,941 16 $ 864 $ 2,077
24 4 2% $ 1,961 8 $ 432 $ 1,529
25 4 2% $ 1,961 8 $ 432 $ 1,529
      $100,000 204 $ 11,016 $ 88,984


As you can see this moves our prioritization around a little bit.  The nice thing about the above is that we can automate it.  In your Agile Management System each feature should accept a VP rank and an duration estimate in Ideal Hours.  You will also want to have a mechanism to enter the Value of the release, $100K in the example above.  Using these inputs your system should be able to auto-prioritize your features for you.  Now that you have cost, you can track EV,PV and AC on your CVE vs. CVP graph.  I don’t like the PMI term “value” in the EV and PV metrics.  Their old names used to be Budgeted Cost of Work Performed(BCWP) and Budgeted Cost of Work Scheduled(BCWS) which I think is more fitting. Either way, don’t confuse the term “value” in these metrics for revenue.  The value they represent is the cost, i.e. the value of the work.  For this example, we will assume that the estimates were correct and AC and EV are equal, that is, there is no cost variance during the release.  The graph would be similar to that of Figure 1.


Figure 1 – CVP, CVE, PV, EV & AC

I know there are some hard-core Agile managers out there who believe that we should not concern ourselves with revenue estimates.  Some think that simply managing costs while we continue to iterate is enough.  If you are of this mindset, let me ask some questions.  How do you know when your costs are nearing your sales?  How do you determine if your project will be profitable?  If given multiple projects to work on, how do you choose the most important one?

I would also like to remind you that I have not taken risk into account yet, which will again change the priority of the features.  I will try to cover this in future posts.

As always, I would love to hear your thoughts on this.

Interview - Dr Eliyahu M. Goldratt

clock July 8, 2009 14:54 by author Chad Albrecht

A great interview with Dr. Goldratt. Many of his comments remind me of the MIT Sloan beer distribution game. What I continue to get from reading Dr. Goldratt is that people solve problems, not processes. While the Theory of Constraints, Six Sigma, Lean, are all good tools, they are implemented by people. Just think about how Bill Smith started using Six Sigma at Motorola or how Taiichi Ohno brought the Toyota Production System together. These were people using the scientific method to solve problems and ultimately improve their companies.

PMBOK, Agile & TOC: Dependent Events with Variance

clock June 15, 2009 10:27 by author Chad Albrecht

The Software Development Lifecycle is really a set of dependent events. Someone has to come up with an idea for a feature, Product Management has to write the requirement or User Story, Development has to analyze and code it, QA has to test it, etc. Each event or process depends on the previous one completing, in essence making each of them covariant on the next. If I want to explain how we can use Throughput Accounting and the Theory of Constraints to manage our software projects, we need to understand Dependent Events with Variance. Dr. Eliyahu M. Goldratt describes the "match game" in his book titled The Goal which illustrates this very well. The game is played as follows:

  1. 6 buckets are laid out on a table.
  2. A person mans each bucket in which matches are placed. The matches and buckets are to represent some type of production process. Think SDLC in this case.
  3. Each person is given matches from the person to his right and places them in his bucket.
  4. The flow of matches is controlled by the roll of a die.
  5. The right-most person rolls the die and gives that amount of matches to the person on his left who in turn places them in his bucket.
  6. The die is handed left and rolled. That person takes the amount of matches less than or equal to the roll and hands them left. The amount is constrained by the amount of matches in the bucket.
  7. Goto #5.

We can measure three things in this game very easily.

  1. The amount of matches consumed by the right-most person. (Raw materials)
  2. The amount of matches in the system. (Inventory)
  3. The amount of matches passed out of the system by the left-most person. (Throughput)

To illustrate this, I wrote a simple SilverLight application that demonstrates the game. Pay close attention to what happens to Inventory.

I will talk about Constraints, optimizations, etc. in future articles.

PMBOK, Agile & TOC: Theory of Constraints???

clock May 20, 2009 08:57 by author Chad Albrecht

Brought forth by Dr. Eliyahu M. Goldratt in his 1984 book titled The Goal: A Process of Ongoing Improvement, the Theory of Constraints is an idea and process that seeks to optimize a system by identifying and eliminating its bottlenecks.  The process is comprised of five, fairly straightforward, steps:

  1. Indentify the constraint.  This means you will need to be able to measure a systems performance in order to identify its constraints.  I will talk more about that in later articles but for those of you who can’t wait, take a look at David Anderson’s book Agile Management for Software Engineering: Applying the Theory of Constraints for Business Results (Coad Series)
  2. Exploit the constraint.  This means that you should do everything within your power to make sure that the constraint (equipment, people, policy) is never idle.  Again, I will talk more about this item in future articles.
  3. Subordinate all other processes to the constraint.  In Lean and Six Sigma this is known as “balancing” and is simply the act of keeping other phases in a process in-line with the constraint. This step introduces the concept of Drum-Buffer-Rope (DBR) as a mental model that can be used to explain subordination.  The Drum is the physical constraint (rate) of the team, the Buffer protects the Drum so it always has work flowing to it and the Rope is the flow of inventory into final product by way of the implemented process.  David Anderson has a good explanation here.
  4. Elevate the constraint.  This is the improvement step.  Consider ways to improve the throughput such as removing inefficient or time-wasting process, hiring more people, buying more equipment or tools.  In my opinion this is where the meat of TOC is and I will spend significant time on this topic in future articles.
  5. If the steps taken in #4 have caused the constraint to move, go to #1.


In future articles I will discuss how TOC can be used to improve the efficiency of your Agile teams primarily during the Planning, Executing and Monitoring phases of your Agile project.

About me...


I am a leader, entrepreneur, software engineer, husband, father, pilot and athlete. Over the last 17 years of my career I have built numerous successful companies and software development teams. This amazing journey has taken me all over the world and allowed me to work in a number of diverse industries. I have had the privilege to meet and work with thousands of unique and talented people. As you will see from my blog I am a strong believer in Agile techniques and the Kaizen corporate culture. I am always looking to grow myself, my teams and the companies I am partnered with.

Contact me... View Chad Albrecht's profile on LinkedIn Follow Chad Albrecht on Twitter Subscribe to this blog

Professional Scrum Trainer

Professional Scrum Developer Professional Scrum Master I Professional Scrum Master II Professional Product Owner I Professional Product Owner II Certified ScrumMaster



<<  October 2015  >>

View posts in large calendar


Download OPML file OPML

Sign in