I enjoy helping people with Scrum and Agile. The more I do it, the more I learn and enjoy it. Many of my recent in person and online encounters have had a similar flavor to them. I didn’t put my finger on it until this morning.

In an online exchange people have been discussing the Sprint Burndown Chart. Opinions on it’s usefulness, how it should be used and what it contains vary widely. That’s OK, because every team and situation is different. The point that struck me was one particular comment. This person described how their chart showed burn down of estimated hours for tasks. They adjusted the burndown each day if a task’s estimated hours to done changed, essentially including actual hours into the burndown.

For example, take a task that was originally estimated at two hours. The next day the developer working on the task reports slow progress.  The task is not done with four hours already spent. The developer now estimates the task will take ten hours. So the burndown chart data point would be adjusted up by six hours to include the new estimate.

This example shows the desire of this particular team to track actual hours. I suppose they wished to compare them to the original estimates to measure accuracy, though that did not come up. (There are several reasons that I don’t like such a way of doing things, but that is another discussion.)

Other examples along the theme have been

• eight hour planning meetings
• estimating an entire five month long Product Backlog all at once
• two days of wireframing before writing the story
• sprint tracking spreadsheets with more detail than a Gantt chart

So when I was thinking about the burndown of actual hours example and other practices of potential waste, the theme hit me:

Big Design Up Front (BDUF) of Scrum

It seems many people are trying to eliminate BDUF of products, with Scrum implementations that are designed big up front.

• They need to define every possible field that might be needed on a story card before they start using story cards.
• They want to track hours and sub-hour increments on tasks, allocated by a percent of the developers time against other tasks.
• They need backlog spreadsheets with date coded story ID’s, date last edited, comments by department in separate columns and priority votes from each of five stakeholders.
• They make up two page forms for recording the definition of done and how each maps to the appropriate use case record(s).

And they do all this before the first team starts the first sprint. Because, well, they’ll need the data, right?

Maybe they will need such tracking of information someday. Any one of the above might be the right thing to do at some point for a particular team or company or product. Does it make sense to design all this infrustructure up front, not knowing if it’s really needed?

BDUF Practices in Scrum

Finally, after weeks of discussion, meetings, documents and planning, they start the first sprint. And here they are with all these BDUF practices now part of their Scrum processes. Product Owners who have more clerk-work than product innovation-work. Scrum Masters who have to keep asking for actual hours worked. Burndown charts that require an instruction sheet to interpret. A project bogged down by the same stuff that was supposed to be left behind by “going Agile.”

Simple Code, Simple Scrum

The best code is simple, direct and no more complex than it has to be. The best products have a clear function and benefit to their customers. The best information is direct, focused and simply presented. The best Scrum is simple as possible. Just as it is not possible to know all the answers to creating an innovative product before starting development, it is not possible to know all the things needed for an awesome and highly productive Scrum process. Start simple, way simple, with just the basic pieces. Then, retrospective after retrospective, the team and company learns what they need, solves it in a simple way and gets back to the real business of creating a killer product.

Just go! You will learn what you need along the way, faster than you ever imagined!

Are your task's edges ragged?

The lawn was out of hand.  I skipped mowing one week for some reason and now it was far too long.  I attacked with the mower and with a desire to get the chore over as quick as possible.

Now with the grass cut low, I began to coil the mower’s extension cord and noticed the lawn’s edges.  They were ragged and unkempt.  I had failed to bring the edger from the back yard storage and was reluctant to take the additional 10 minutes or so to retrieve the edger and complete the task.  Besides, I had mowed the lawn, right?

“The lawn looks fine to passers-by,” I rationalized.  “Only people looking closely or actually visiting the house will notice the ragged edges of green.”

Declaration of Done Too Soon

Many times in design we are anxious to be done with a task or story.  It’ll look better on the burndown chart or on the task board if we call it done right then and fix up the “ragged edges” later.  We rationalize:

“It’s done and tested, I’ll check it into the repository and build system tomorrow.” Or “We should make sure the interface is the same as the previous version but nothing should have changed, so, let’s go to PCB.”

In agile practices, it is acceptable to define done as “just enough” to satisfy a story.  This is good since it prevents waste creating lots of details that have a high probability of changing.  But changing the definition of done to match incomplete or buggy results is a great way to build up technical debt.  The velocity of progress in subsequent sprints will suffer as the team has to put the final touches on what should have been done before.

Power of Transparency and Completeness

Keep your definition of done tidy!

Scrum and agile practices draw power from transparency of both process and reality.  This power has many benefits like:

• The customer knows what they are getting and when.
• The enterprise trusts the team to produce their commitment.
• The team enjoys space and time in the sprint to do their work.
• The end product actually works and has minimum bugs.

Harness this power!  Be honest with the team and your customer and make sure that something declared done really is done.  And make sure you always do the edges!