Earned Value Analysis for Feature-Burndown in Iterative Projects

Name: Earned Value Analysis for Feature-Burndown in Iterative Projects
Type: Process
Status: final
Version: 2008-03-27

Gist: to explain how to obtain information about the Earned Value of an agile project that is using a backlog of either {user stories, features, requirements, change requests}

Source: T. Sulaiman, H. Smits in Measuring Integrated Progress on Agile Software Development Projects. In addition, there's tons of information out there on Earned Value Analysis, check out:
http://en.wikipedia.org/wiki/Earned_value_management
www.earnedvalueanalysis.com/
www.projectlearning.net/pdf/I2.1.pdf

feature FOR THIS POST DEFINED AS a thing to be implemented, could well be a requirement, a user story, a use case. Whatever your backlog consists of.

Entry-Conditions:
E1: Each feature in your backlog needs to have an estimate, best measured in some points, gummy-bears etc. (Make the sum of all features your parameter TSPP, total sum of planned feature points)
Note: It's not imortant that these estimates represent actual budget, time or similar. They have to be consistent with each other and represent properly the relative relations between them
Note: You can adjust the number later but you will have to recalculate things (see S3-S5).
E2: You need to know how many iterations you will undertake. (Make this your parameter TNI, total number of iterations).
Note: Ideally, iterations are all the same length, i.e. timeboxes. You can adjust the number later but you will have to recalculate things (see S3-S5).
E3: You need to know the budget you are about to spend, from now to the end of the last iteration (make this your parameter TBP, total budget planned).
E4: You need an established way of tracking how much budget you have actually spent on each of the iterations.
Note: This can be obtained by maintaining a log of workhours spent on the project by each of its members.

Process:
S1: After every iteration, find out how much budget you have actually used for the iteration. Sum it up over all finished iterations. Make this your ABS, actual budget spent
S2: After every iteration, find out how many points you have actually implemented within all iterations (= ASI, actual sum implemented). All the feature's points count as implemented if and only if the feature is in full effect.
Note: this means you have to have a clear understanding what 'done' means for a feature.

S3: Do some calculations
- Expected Percentage Completed = TNI / number of already finished iterations
- Actual Percentage Completed = TSPP / ASI
- Planned Value = TBP * Expected Percentage Completed
- Earned Value = TBP * Actual Percentage Completed

S4: Find out about you projects cost performance and cost estimate:
- Cost Performance Index = Earned Value / ABS
Note: > 1 means under budget, = 1 means on budget, < 1 means over budget
- Cost Estimate to Completion = TBP / Cost Performance Index

S5: Find out about you projects schedule performance and schedule estimate:
- Schedule Performance Index = Earned Value / Planned Value
Note: > 1 means before schedule, = 1 means on schedule, < 1 means behind schedule
- Schedule Estimate to Completion (in iterations) = TNI / Schedule Performance Index

How to figure out what the problem really is

Name: How to figure out what the problem really is
Type: Principles, Process, Rules
Status: final
Version: 2008-03-27
Source: Don Gause & Gerald Weinberg, Are Your Lights On?; two own thoughts

Problem DEFINED AS difference between things as desired and things as conceived
Note: Don's and Gerald's original definition stated 'perceived' instead of my 'conveived'. I changed this due to some buddhism-oriented mindset of mine. Thanks to my friend Sven for reminding me.

Principles
P1) Each solution is the source of the next problem.
P2) Moral issues tend to melt in the heat of a juicy problem.
P3a) You can never be sure you have a correct problem definition, even after the problem is solved.
P3b) You can never be sure you have a correct problem definition, but don't ever stop trying to get one.
P4) The trickiest part of certain problems is just recognizing their existance.
P5) There are problem solvers and solution problemers.
P6) In spite of appearances, people seldom know what they want until you give them what they ask for.
P7) The fish is always last to see the water.
P8) In the valley of the problem solvers, the problem creator is king.

Process
S1) Ask: Who has the problem? Then, for each party, ask: What is the essence of your problem?
S2) think of at least three things that might be wrong with your understanding of the Problem. If you can't think of at least three things that might be wrong with your understanding of the problem, you don't understand the problem.
S3) Test your problem definition on a foreigner, someone blind, or a child, or make yourself foreign, blind, or childlike.
S4) Generate points of view. Every point of view will produce new misfits between problem and solution.
S5) As you wander the weary path of problem definition, check back home once in a while to see if you haven't lost your way.
S6) Once you have a problem statement in words, play with the words until the statement is in everyone's head.
S7) Ask: Where does the problem come from? Who sent this problem? What is she trying to do to me? The source of the problem is most often within you.
S8) Ask yourself: Do I really want a solution?
S9) Ask Why 5 times. Normally this leads you to the essence of the problem.
S10) If a person is in a position to do something about a problem, but doesn't have the problem, then do something so he does.
S12) Try blaming yourself for a change - even for a moment.

Rules
R1) Don't take s.o. solution method for a problem definition - especially if it's your solution method.
R2) Don't solve other people's problems when they can solve them perfectly well themselves. If it's their problem, make it their problem.
R3) If people really have their lights on, a little reminder may be more effective than your complicated solution.
R4) If you solve s.o.'s problem too readily, he'll never believe you've solved his real problem.
R5) Don't leap to conclusions, but don't ignore your first impression.
R6) We never have enough time to do it right, but we always have enough time to do it over.
R7) We never have enough time to consider whether we want it, but we always have enough time to regret it.

Finding the Right Cycle Time - 10 Rules

Name: Finding the Right Cycle Time - 10 Rules
Type: Rules
Status: final, revised
Version: 2008-08-08

Gist: to explain what influences cycle time in an agile development and how to find the right time for a given situation
Sources: Implementing Lean Software Development, Mary and Tom Poppendieck, Addison Wesley, 2007; own experience; a talk of Mishkin Berteig at Agile 2008

R1: Think about 1 day, 1 week, or 1 month for a start.
Notes:

• You don't have to predict a useful cycle time for a whole 1 year project in advance. Start with anything that seems to useful for the next, say, 25% of the project time, but start now.
• 1 day may seem rediculuos. It isn't. it is likely that people agree to do such an 'experiment'. you get things rolling, everybody is happy about the exercise and you can gather data from your team! Also see R9.
  

R2: Listen to what your team says. Ask why every time someone comes up with an argument against a specific cycle time. Account for the natural resistance to change. Do baby steps towards a change
Note: there's also a valid thought against baby steps. If you try to reduce cycle time from 3 months to 2 weeks, it's tempting to go for 4 weeks first. However, if you decide to *start* with 2 weeks, your will double the chances to learn anything useful.

R3: If your cycles get hectic near the end, you should reduce cycle ime to even out the workload.

R4: If your customers are trying to change things while a cycle is underway, if they cannot wait until the next cycle, then your cycle time is too long.

R5: If you cannot release software very often, think about doing smaller cycles (iterations) within larger cycles (increments, releases). However, make sure that you really can't release more often.
Note: In some organisations, it is painful to change processes so that certain acceptance tests would consume less time. or maybe you have a great many users of your product and you can't find an efficient way to train them new features. But be careful, these arguments may not be the real ones. Keep asking why.

R6: Resist the temptation to do parallel cycles unless you know exactly what you are doing. It's very hard to maintain a strong notion of 'done' if you do it. Do not assume you need it because otherwise the team would not be utilized properly.
Note: Full utilization will slow your team down. Full stop.

R7: Make sure everyone, especially your customer, understands this one "Time, quality, scope - choose any two." -- Greg Larman

R8: If your managers want reports quarterly, surprise them with a telling set of data concerning your progress, not only one cycle's experience or less. Prove to really being in control and to really getting things done.

R9: If you seem to have a rather gigantic amount of things do be done in your project, go for shorter cycle time. You will soon have a pretty good sense of your velocity, thus being able to predict what you will be able to achieve.
Note: However, you have to adjust your prediction after the first 2-4. A very effective way of gathering this amount of data is doing EXTREMELY short iterations (1-day) during the first, say, two weeks. This is EXTREMELY useful to get a waterfall team do short iterations. Most people are willing to do an experiment that is that short. See R1.

R10: If more than 1 or 2 features can't be completed within one cycle, break the features down.

Simple Solid Decision Making

Name:
Type: Process
Status: final
Version: 2008-02-01

Gist: how to make well-grounded decisions even if you cannot use Tom Gilb's Impact Estimation method for some reason (see Gilb, Competitive Engineering, Elsevier 2005). Decision making is the process of choosing a solution to a problem from a set of solutions, given a set of goals.

Sources: Stefan Brombach (http://www.dreizeit.de/), Kai-Jürgen Lietz (Das Entscheider-Buch, Hanser 2007), Tom Gilb, own thoughts.

S1: Make clear the goals of your endeavour. you need to understand what you want to achieve, what you want to keep and what you want to avoid. Consider using the Decomposing Goals principles.

S2: If you have many 'small' goals, say more than 12, then consider integrating some of them in a more abstract goal. Example: 'low costs for running the application' and 'don't exceed the budget' could be combined into a 'cost' goal. If you have to be quick and can't afford doing step S1 (please really consider doing it!) take the common three goals {time, scope, quality}.

S3: Compare each goal with every other goal. The more important goal gets a point. If you can't decide which one is more important, give 0,5 points to either goal. In the end, add 1 point to every goal for every goal has at least 1 point. Now you know the ranking of your goals in terms of importance.

S4: Go find at least three different realistic 'solutions' or ways of achieving your goals. You need three or more to have a little room for manoeuvres. Bear in mind, if you only have one solution there's nothing to decide.

S5: Using a 0..3 scale, iterate through all your solutions and goals and again give points to the solutions. 0 means solution X does not help achieving goal Y at all, 3 means it helps a great deal. Multiply these points with the importance of the goal from step S3.

S6: For each solution, add all products from step S5. The solution with the largest sum wins.

Lean Development Principles

Name: Lean Development Principles
Typ: Principles
Status: final
Version: 2008-02-26

Quelle:
See: http://www.shmula.com/340/lean-for-software-interview-with-mary-poppendieck
Chris's article on InfoQ

P1: Flow (or low inventory, or just-in-time) (inventory DEFINED AS something partially done)

P2: No Workarounds, problem exposure
Note: if you encounter problems, solve them, don't take detours. This may mean you have to stop what you are doing.

P3: Eliminate Waste (waste DEFINED AS {something without value to the user, work partially done, extra feautures you don't need right now, stuff that causes delay})

P4: Delayed Commitments (DEFINED AS idea of scheduling decisions until the last moment when they need to be made, and not making them before that, because then you have the most information. -- Preston Smith)
Cite: "Never make a decision early unless you know why." -- Chris Matts

P5: Deliver Fast (DEFINED AS being able to quickly release software. You need proper procedures for that, like {excellent testing procedures, automated testing, stuff that is disjoint from each other (so as you add features you don't add complexity)}
Note: A rigid process menas less choices you have to make every day. Less choices mean more output. Routine enables innovation where it’s most valuable.