Burnup or Burndown

A burndown chart shows how much work is left to do. For example, a release burndown will show the amount of story points left on the backlog for a particular release, or a sprint burndown will show the amount of ideal (golden) hours left for the current sprint.

A burnup chart shows how many running, tested, features have been done and is thus more value-focussed.

What is the difference?

A burndown chart tracks net progress. It doesn’t easily depict changes in scope. For example, if we have 100 story points to burndown and we discover 20 missed points whilst completing 50 then we still have 70 left to do.

A burnup chart tracks gross progress.

When would you use each chart and why?

In Scrum, a burndown chart is best suited to depicting sprint progress because scope is not permitted change during a sprint. A burndown chart also gives the team a sense of an end goal (the ‘getting to zero’ feeling). On the other hand, a burn-up chart is best suited to depicting overall product progress because scope is likely to change throughout the lifetime of the project. Burnup will easily communicate these changes in scope because a change in the top line clearly indicates this change.

So why might you use a burnup chart for a sprint or iteration?

A burnup chart being used for tracking a sprint or iteration is generally a sign that a team is unable to work out its’ velocity. This can happen for a number of reasons, most notably:

• Poor estimation – tasks are not broken down into small enough pieces (rushed planning meeting)
• Unclear stories (information provided is often unsuitable)
• Poor acceptance criteria (not done before or during sprint planning)
• Missed tasks, such as reporting
• Working on items not in the sprint (such as items slipped in undercover, bugs or management tasks)

GIF

GIF (Graphics Interchange Format)

• Uses a palette of 256 colours
• Handles solid colours well
• Handles sharp edged line art well
• Doesn’t handle gradients well (can be handled with dithering and blur)
• GIF allows interchange of images / frames to support animation
• Handles transparency on block objects
• Uses matting for edges of graphic & transparency

A Bug is not a Bug unless you provide

1. Steps to reproduce
2. What you expected to see
3. What you saw instead

ASP.NET MVC Attributes

There are attributes available in ASP.NET MVC that allow us to handle common scenarios consistently and easily, such as:

• [Authorize]
• [HandleError]

We are using these in some places and not in others. Maybe we should take the time during development tasks to investigate different ways of doing things.

Criticise ideas, not people

Don’t do this:

“You have a lot invested in your design. You’ve put your heart and soul into it. You know it’s better than anyone else’s. Don’t even bother listening to their ideas, they’ll just confuse the issue.”

DRY (i) Don't Repeat Yourself

"Duplication may be the root of all evil in software." (ii)

Duplication slows you down and makes your code more error prone. If the same code has to be changed in more than one place you may/will miss something.

Dupliction appears in many disguises, but there are ways to deal with it so don't worry...

1) Clumps of identical code/CPS (iii). Consider using extract method or extract class followed by highlight and delete on the remaining offenders.

2) Conditional logic testing for the same set of conditions (switch/case OR if/else). Consider polymorphism.

3) Database schema. Consider using normalisation, it can be a winner

In short duplication stinks, exterminate it ruthlessly.

(i) Andy Hunt and Dave Thomas - The Pramattic Programmer
(ii) Uncle Bob - Clean Code
(iii) CPS © - Copy/Paste Syndrome - James Enock 2009)

Add Nothing But Value

Lean : Eliminate Waste

What is waste?

Waste is anything that does not add value, such as defects not caught by tests, developing features not required for the current sprint, not coding directly from stories, etc

Mary Popendieck provides a table for waste in software in her paper Principles of Lean Thinking which also demonstrates how XP addresses waste.

Seven Principles of Lean Software Development

1. Eliminate Waste
2. Create Knowledge
3. Build Quality In
4. Defer Commitment
5. Optimize the Whole
6. Deliver Fast
7. Respect People

See also: Agile Software Development.com