I was thrilled to read “Agile Principles and Achievement of Success in Software Development: A Quantitative Study in Brazilian Organizations” by Paulo Henrique de Souza Bermejo et al. Why is it so exciting? Because the authors use a novel approach to quantitatively and statistically evaluate what software development organizations do and how that is linked to success. Continue reading →
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 client to come out with what they expect to achieve from a Project.
Image above depicts the Fibonacci series, which is used as one of the sizing techniques for User stories.
How much change can a project withstand before it is too much? A requirements change rate of above 20% is probably too much . Typical rules of thumb figures for software development requirements change rate is cited as 1-3% . But the rate of change is accelerating. In 2002, 10% was not uncommon . How high is it now? Continue reading →
As a consultant and as an agilist I have a vested interest in trust. Trust might be seen as one of the top two factors for success in software development projects . Most of us have a vague idea of what is needed to create trust. Charles H Green of The Trusted Advisor has come up with “the trust equation“. I first learned about the trust equation in one of Joe Dager‘s excellent podcasts. Continue reading →
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 and how to apply them — or not… Continue reading →
I’ve started blogging at the Capping IT Off blog. Posts there will be about topics that are off topic for this blog. My first post is about e-health innovation and apps. My conclusion? E-health will be powered by thin, targeted applications built on a stable framework.
I’m a strong believer in learning by doing. I also believe that learning will be better when supported by an agile community of practice (CoP). Communities of practice allow self-selected members to develop their “capabilities, build and exchange knowledge”. In my professional life, I am involved in several communities including larger associations such as IEEE and ACM but also more focused communities at work including on Enterprise Architecture, E-health and Agile.
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:
Start with your user stories + other backlog items then FOR EACH
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
Now that your item is sufficiently small, think about the worst case and estimate it again
Now think about the best case, estimate again
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.
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. There is no one in the room who can address or resolve them. Continue reading →