Software Development Success

A roadpost pointing to success or failure

[bibshow] Software development success is organization dependent. Which organizations are successful in developing and delivering software? Which projects will be successful? That is a crucial question in an industry with an annual turnover of over 400 billion USD and only a 50% success rate. [bibcite key=”citeulike:4540645″] Is it enough to…

Continue reading

Agile projects requirements breakdown structure

fibonacci series in nature

In Agile projects, when a set of requirements are received from Clients, it may consist of (a mix of) A few needs, objectives, goals and some partial stories (even though it would have come in a structured document). Re-organizing (re-arranging) those into a requirements breakdown structure (RBS) helps ask right questions to…

Continue reading

Change is the only constant in agile

Neon sign: change. Change is the only constant.

[bibshow] How much change can a project withstand before it is too much? A requirements change rate of above 20% is probably too much [bibcite key=”citeulike:13415962″]. Typical rules of thumb figures for software development requirements change rate is cited as 1-3% [bibcite key=”citeulike:321639″]. But the rate of change is accelerating.…

Continue reading

Software Effort Estimation Problems

Estimation is important for software developers. Software effort estimation problems are part of their daily lives.

Software effort estimation is an important part of the daily lives of many software professionals. I have joined the #noestimates debate on Twitter because there is a lot to learn from a discussion on estimates. I’m not ready to fully abandon estimates but I am interested in discussing where, when…

Continue reading

Combining Traditional and Agile Estimation

Can you combine traditional and agile estimation? There is nothing magical about “classical” estimation. There are a few basic concepts to keep track of:

  • Bottom up versus top down
  • Expert estimation versus parametric estimation
  • Best – worst – expected case

I think the most common method for traditional estimation is to go top-down using successive estimation which means that when something is to big or uncertain, you break it down into component tasks and estimate them recursively. If you are familiar with Planning Poker you can easily combine it with this approach:

  1. Start with your user stories + other backlog items then FOR EACH
  2. Estimate it with PP, if too big or to wide spread it is an Epic. Break it down into smaller stories (this creates your WBS) and GOTO 2
  3. Now that your item is sufficiently small, think about the worst case and estimate it again
  4. Now think about the best case, estimate again
  5. Calculate the weighted average as (best + 4* “normal” + worst) / 6

Not so different from “pure” Planning Poker, is it? There are a few improvements you can do though — instead of using three estimates for each item, you could use the spread of estimates you already have from PP as a basis for your probability distribution.

What is the proper size and time for an Agile Retrospective?

I often hear the same complaint about Agile Retrospectives: They are not held at the right level in the organization! Or, at least, that is the conclusion that people draw from one fact: Many issues brought up in the Retrospective need resolution at a much higher level in the organization.…

Continue reading

Improved Agile Estimates

Planning poker is a first step towards improved agile estimates.

Do you need improved agile estimates? If your agile process is heavily reliant on effort estimates, then chances are that you need to have the best possible estimates. Are your estimates already as good as they can be or do you need improved agile estimates?

Continue reading

Key Agile Practices You Need

Laurie Williams presenting a slide. She is the researcher behind the list of Key Agile Practices.

Laurie Williams has presented a “top thirty” list of key agile practices. The list defines what you need to do to be seen as being agile. Continuous integration, short iterations and done criteria are at the top of the list.

Continue reading

Agile is NOT new and not enough

So people keep talking about the Agile – Waterfall dichotomy. About agile and un-agile practices. I decided to have an unscientific look at what Agile isn’t. If there is a true dichotomy between Agile and Waterfall, then things opposite of Agile should be either entirely out of scope for projects…

Continue reading

Agile Estimation Units (revisited)

A team estimating their next iteration using planning poker. What agile estimation units are they using?

Continue reading