Burndown charts as an indicator...

Jack Milunsky posted an interesting point in the Agile Project Managers group on LinkedIn. I normally agree with him and like his work (actually, I still do here)...

His core point is quite valid. The point of the burndown shouldn't be to drive a team towards focusing on the team's ability to match a perfect trend line. This is something I totally agree with. I've seen teams with perfectly straight lines on their burndown and I've learned that this is a big flag! That being said, his following sentence:

I believe that the underlying goal should not necessarily be about staying below the estimated time line in a burndown chart (although this would be nice).

..might set the wrong tone for a newbie to agile. I wanted to address that here.

Joe Blotner captures this well with the following statement:

Scrum doesn't solve your problems, just make them visible, so you can solve them.

...which I'm sure that Jack would agree with.

But... I want to state that I think the main goal of a burndown IS to trend downwards. This isn't the same as staying below the estimated line, but I want to be clear... if the trend isn't down, then you are going backwards. As a business person (PO), I would not accept a burndown going up or flat too long. This is a sign that I'm spending money and there's no sign of progress (both in uncovering all the unknowns and in making progress). I'd almost prefer seeing the line spike up and then start working back down so I know the problem is behind us. A flatline always triggers me to ask "but when will it end?"

That being said, if this is what was happening before agile, then Joe is correct. Agile has helped you focus on this and now you can try and fix it.

Little nuances I know... but I wouldn't want to see a new scrum team looking at their burndown and saying... "eh, that's okay for now... let's figure it out in a few days (or at the end of the sprint)."

Sprint backlog meets fundraising...

Sometimes I see agile in everyday interactions (see prior post about the Kindergarten Kanban board).

My son goes to a daycare in a church. The other day I was walking out with him and I saw the following (click for larger image):





















We've all seen the "thermometer" fundrasier boards where the local non-profit raises the red bar in the thermometer in the scale to entice people to raise the amount needed. What this church realized is that people will feel more invested if they actually know what the money will be spent on.

Enter the prioritized backlog on the fundraiser board. It is very clear that the group in charge is saying that the first dollars will fix the problems, the next chunks of money will think about the future, and the extra money can be spent on some nice to haves (and the remainder will be saved). It's not about raising X dollars, it is about raising the money for the individual projects.

People will feel invested to get involved. Every week they can look at the board and say "Look, we should help pitch in for that." The customers are getting immediate feedback. An expectation and accountability is being set for seeing these projects happen, because it is what people paid for!

Imagine if you could determine where your tax dollars were spent. What impact would that have on paying taxes and government funded projects?

Prioritizing your backlog and exposing it to your team and customer can be a good thing. I hope you appreciated this example as much as I did!

NFR's and Technical Debt...

Two reposts due to their interesting topic and unique content:

1. Non-Functional Requirements, a minimal checklist at Leading Answers. This is a good checklist for any team to work with their product owner and cover all that "technical stuff" that insures the product's success or failure outside of its features. Some people call this the "-ilities" list.
2. Using the Mikado Method to pay down Technical Debt. This is a good post that uncovers the typical lesson of refactoring the guts of a ball of mud. For every thing you fix, you find 10 more. The Mikado Method is a good way to plan out refactoring to avoid this problem.
   

RP: 10 activities of PO

Repost: From Jack Milunsky on the ASD blog, post about the 10 activities of a Product Owner. Bullets summarized here, read full post for details.

1. create/maintain product backlog
2. prioritizes backlog
3. assists with epics->story breakdown
4. conveys sprint/release goals
5. represents, interfaces, engages customer
6. participates in standing and sprint meetings
7. accepts/rejects sprint deliverables
8. can redirect team/project with each sprint
9. communicates status externally
10. can terminate sprint early if drastic change is needed

Don't abuse the metrics...

Tim Ross blogged about his concerns on burndowns. He offers some interesting points on how they can hurt including:

1. too much pressure early on
2. it doesn't handle the unplanned
3. it is unforgiving
4. PM's and customers misread it
5. it discourages refactoring
6. it focuses on a predetermined time

Hmm.... my responses:

1. really? most people feel it at the end
2. it is a reminder of the reality of the clock
3. neither is the market, it is changing whether you deliver or not
4. well... yes, that's true with any data point
   
5. not if you refactor constantly
6. or you could say it focuses on meeting a completion of commitment
   

Okay... some of that is me playing devil's advocate. I can relate to some of the points that Tim makes. Unfortunately, he proposes a solution where teams focus on the task board and maybe even hide the burndown for only the manager's eyes.

Umm... no. If you are really interested in going agile, then you have to understand that there is a power shift from the managers to the team. Instead of having people above (who aren't doing the work) ask for ridiculous things and make useless statements, the team is now more in charge of the process. But, the idea of a self-empowered, self-managed team is that the team has to be willing to be accountable for the work. This is not just the validation and quality of that work, but also the predictability of its timely delivery.

My view on this matter is two-fold:

• The burndown is an indicator. Bad trends in burndowns should be a flag for resetting expectations. When expectations are adjusted (be it the developers, customers, or managers), then everyone should know about it (that is why we do sprint planning and sprint review together, right?).
• ANY METRIC can be abused. If your culture stinks, or there isn't a trusting relationship between the team and the customer or managers... then any metric can be abused to support finger pointing. This is not specific to the burndown.
  

This is why many waterfall projects fail. It takes so long to uncover problems that when they are realized by lower management, they can delay the discovery further by gaming the metrics and reports to protect their jobs as long as possible.

"My definition [of agile] is that you accept input from reality, and you respond to it" - Kent Beck

A burndown is one of many measurements of reality! Unfortunately I think the answer in this situation is that the group needs to improve the cultural issues instead of throwing out the burndown.

Non-Functional Requirements...

If you haven't heard, there's been some buzz about non-functional requirements in both the community (InfoQ) and from the experts (Mike Cohn). I'm also seeing some activity in the Agile Alliance LinkedIn group.

Agile Risk Planning...

I'm going to oversimplify a lot of things in this post. I'm doing it for two reasons... it's not the most interesting topic, and I'm really just trying to throw out a very basic solution to what can be a very complex process. Many environments don't even do risk management, so my theory is that something light covering 60% of your needs is better than nothing at all.

What do we know about Risk Management?

Well, we are supposed to do our best to anticipate what might happen and mitigate it. The best way to do this is:

1. make a list of all the bad things that make you lose sleep (or just worry you)
   
2. assign a probability of each happening
3. assign a cost of impact if they occur
   
4. multiply all of the probabilities by all of the costs and get a total cost
5. put that money in the bank (or time padding on the project plan) to protect against it
6. constantly manage the list to your best knowledge
7. make decisions about how to spend resources to mitigate or remove risks (if you can do this for a fraction of the cost of it actually happening)

Your approach to this could be very scientific, thorough, and accurate... or you could just make some quick gut calls.

What is the agile solution I propose?

First, I believe that the amount of time needed to be invested in this process to make it very accurate is an amount of time and resources that most teams don't have. This is the same issue as estimation for stories and tasks in agile. There's a reason we do poker planning, and it think it might apply here.

1. Let's start with the basics... have the team spend a few minutes each release (every few sprints) brainstorming risks with the guidance of a PM and the PO. The PM, PO, and Scrum Master should have already pre-seeded the list to speed things up since this isn't the main focus for the team.
2. Now assume the risk will occur. Have the team estimate the impact of the risk using the same scale you estimate stories by.
3. Using poker planning, assign a probability of each happening (but use a scale of 1%, 10%, 25%, 50%, 75%).
   
4. Multiply each of the probabilities by its corresponding cost and sum for a total cost. This is your risk budget.
5. Here's where I assume you have an electronic version of your backlog (be it excel, or a tool like VersionOne). Add a story to the bottom of your backlog called Risks. Under it, create a task for each risk. Put your total risk budget as the story estimate.
6. Go.
   

Your system should include this story in any projections it makes for the burndown chart... so now you have that buffer built in to your projected product backlog. You have hedged your bets against the risk odds, and your are reasonably protected without being overly protective.

Responsibilities moving forward:

• Management is responsible for keeping this list up to date. Add/Remove risks as appropriate.
• Any work that can be done to reduce or remove items in this list at a fraction of the cost of the risk occurring should be pursued.
  
• The team should re-estimate both probability and impact cost periodically based on their updated knowledge (this supports the cone of uncertainty philosophy)

That's it... that's my poor man's soluton. Time to apply it and see if it is "just enough".

Final Note- Since I'm not as experienced in hand's on Risk Management as I could be, I welcome any ideas or feedback on this post... especially errors in my thinking. Feel free to beat me up. Most of the places I've worked, I haven't had time to focus on risk because the biggest issue is teaching people how to make and follow a plan along with communicating well as a team (hence my interest in agile).

Update (11/25): Here are two very good articles by James Shore about risk management and estimate inflation if you want to see a more in-depth look at these topics.

Are we there yet?

Are we there yet?
Are we there yet?

Have you ever been driving and heard this from the back seat? I don't have kids that are old enough yet, but I've seen it in the movies plenty of times and am not looking forward to it.

I once found myself saying this when on a flight to Japan. 13 hours on a plane will make you go a little batty. The thing that saved me was the projection on the wall showing the plane relative to the earth with a miles and minutes countdown to landing. Every time I asked myself if we were there yet, I had the answer right in front of me.

When the jetstream shifted and the flight was delayed, this was immediately shown on the screen with the new projection.

Sound familiar? Sounds like a burn-down chart to me (minus the history).

When the plane first took off, a projection was made immediately even though we hadn't made any progress yet. How'd they do that? Sounds like they used yesterday's travels to determine velocity.

When I download software from the internet to my computer, it gives me a sense of how much is complete and how much time remains. This is constantly adjusted as more pieces and packets arrive.

All of these methods make more accurate projections as progress is made.

In some form, ever since we've had the ability to provide this type of feedback on planes, gps devices, software downloads, etc... we've been staring the burndown concept in the face. Why did it take me so long to want this in my daily job?

What is sprint planning about?

There is a good discussion forming on the VersionOne google group about sprint planning. As people were starting to weigh in, I found myself writing more than a forum response... so here's my blog post about it. On my last review, I cut chunks out of this to shorten it... so there is much more to say on this subject.

The following is a description based on my last environment since it was a more mature agile team. We always treated sprint planning as a time-boxed event.
_________

A major goal of sprint planning is to make a commitment to what is intended to be delivered by the end of the sprint.

To do this, you:

• need customer/team input on what items from prior sprints need revisiting before moving forward (incomplete stories)
• need product owner/customer input on what is important to tackle next
• need estimates on these items to understand relative size (unless everything is sized the same)
  
• need an understanding of team velocity

Sometimes sprint planning will already have all these things completed (may happen throughout the sprint and during review), but if not, this should be the first focus during sprint planning.

• First bullet, assess the realities of where you are. There might be items that were rejected during sprint review for whatever reason that now need follow-up work before being marked as DONE. Also, a mature team might have a few stories started for the next sprint because they've learned how to keep their cadence and view sprint boundaries as a point of measurement instead of a true work-stop.
  
• Second bullet, have a prioritized backlog. It might shift throughout the sprint due to changing conditions from the market, the feedback from the users, or the complexities uncovered while building the software. This needs to be reviewed and updated so the team understands what is near the top of the list.
• Third bullet, perform just in time design. As items were put on the backlog, enough design should have been done to estimate them in comparison to each other and properly size them. Now the design should be discussed further to insure that anyone on the team has an idea how they would tackle the work and could see themselves taking it on (but leave the black-box details to the folks doing the work during the sprint). If you have specialized resources, then it might be possible that only those resources need to be involved in that conversation (not my personal preference).
• Fourth bullet, how much does the team normally get done? This is your velocity.
  

In an immature agile team (or one with current difficulties) this may be as far as you get during a time-boxed sprint planning session. The agile coach or scrum master can guide everyone on how it will go forward from there. Slice of the top an amount of work matching your velocity and go!

Of course this isn't optimal. So, if you were well-prepared and still have time after answering these questions... then what?

The team reviews the backlog and makes a selection of work they will target for the sprint. They should take into account things like removing risk earlier, not stumbling over each other in the code, the knowledge they have on the team, specialized resource bottlenecks, etc. This may lead the team to negotiate with the customer or product owner to skip over something at the top of the backlog for now.

This is the optimal minimum point to get to for sprint planning. A list of backlog items (stories) that the team has committed to tackling that is also acceptable to the customer / product owner. This is a set list that can be statused, monitored, and managed throughout the sprint. Because the team committed to it, there is a level of accountability that people will take responsibility for.

If you still have time in sprint planning, I've seen some groups break down the stories into tasks. If the team is mature, they can do this without knowing/caring who will do the work later (including task estimates). If not, then they might want to wait until someone picks the story up themselves. In really immature teams (technical immaturity, not necessarily agile), the architect or senior members may lay out the task work and estimates as a guide for the junior team members when they get to it. At this point, there's a lot of variance based on the team's needs, culture, skill sets, agile maturity, etc.

The bare minimum is that the team walks out of sprint planning with a commitment for sprint delivery that they can hold themselves accountable to. Explicitly this is a selection. Implicitly, this is the top group of stories that add up to their prior sprint's velocity.

Don't mulch your backlog...

Jeff Patton tells a great story about his work with Gary at Mimi. It's a discussion about the typical approach to flattening product backlogs and how this is destructive to understanding the larger picture. Favorite section:

"We spend lots of time working with our customers. We work hard to understand their goals, their users, and the major parts of the system we could build. Then we finally get down to the details - the pieces of functionality we'd like to build. In my head a see a tree where the trunk is built from the goals or desired benefits that drive the system; big branches are users; the small branches and twigs are the capabilities they need; then finally the leaves are the user stories small enough to place into development iterations."

"After all that work, after establishing all that shared understanding I feel like we pull all the leaves off the tree and load them into a leaf bag - then cut down the tree."

"That's what a flat backlog is to me. A bag of context-free mulch."

I need that context in order for me to really tell a story about the system.

He goes on to discuss the problem further and also the approaches to solving the problem. Very good post. I'm adding it here for my own reference and in hope it helps you too.

Backlog Poker Prioritization...

Peter Stevens wrote a great post over at the Agile Software Development blog about how to tackle prioritizing your product backlog when starting a new project. He lists several approaches to this including:

Minimum Marketable Feature Set - the first pass to narrow the list of stories

Business Value First - Focus on High Value Functions

Bang For Buck - Go for easy wins

Technical Risk First - Do the hard things first

Defer Risk - Do the hard things later (or never)

Vote - Ask your users

He then provides an overview of each of these which I will let you read on your own there.

When he asked for other experiences, I mentioned the following:

We had a product where the backlog clearly could not be covered in the first release. Our customers were hospitals that didn't budge on "their needs".

We pulled our top 10 highest paying potential customers into one site and gave each one a bag of poker chips. They were asked to "pay" using their chips for certain features. They were told they could plop all their chips on one feature, or spread evenly across many.

As they saw each other "pay", they shifted their chips around. They didn't "waste" money where their peers didn't care, and they spread money to provide emphasis where peers needed help.

We walked away with a greatly pared down set of features that everyone was invested in (pun intended) and they felt like they were part of the process.

That's what we ended up building.

Product management...

This article has a little but of mud to work through, but check this out if you're interested in product ownership and management within agile.

My favorite point that it makes: "The top determinant of a product’s revenue success is whether it meets real customer needs and is targeted at appropriate market segments."

Also amusing, they challenge (and apologize) for questioning Ken Schwaber on ranking backlogs based on ROI.

Low Hanging Fruit...

I've worked with product owners or customers that complain that marking an item on the backlog as low priority instantly sends it to the graveyard to live for eternity and never return. They know that the branding, design, and usability issues on the site are cheap to fix but are not important enough to prioritize in isolation.

Solution?

When you have enough, group them together. Have a story that is "improve the experience of your sign-up process". Lump all those design, usability, and branding bugs into one story and make the team bang through them. (Of course, maybe they shouldn't have gotten through acceptance in the first place, but I needed an example and this reflects reality in a couple places I've worked.)

Another option: When the team picks work for a sprint, they pick up a few big stories and typically have a point or two of left over space. Make them pick up some cheap stuff off the bottom. Have them pick based on closeness to other stuff they are touching. Or have them pick based on value. After all, getting $10 of value for 30 seconds of work is slightly better than getting $1000 of value for over an hour of work.

This was the idea behind the first part of my comment about backlog prioritization on vikramadhiman's agile diary blog.