Feature burn up / completion chart

MMFs: the Minimum, Marketable, Features

As I describe in my book, Agile Release Planning, an MMF is a group of minimum functionality that we can release to customers. By 'marketable' we mean that the functionality can be released to customers for their use, and thus the word 'marketable'! So, by definition, MMFs must bring significant value to customers.

As MMFs are of most value to customer, it makes sense to track the progress we make on them. Feature Burnup chart or Feature completion chart is an invaluable tool in your toolkit. It is simple yet very effective chart that you can use to convey progress (or lack of progress) that you are making on various work slices that are of interest to business.

Here is an example for the sample project that I mention in my book:

In this chart we are plotting MMFs on x-axis; in the order of priority, with highest priority item on the left, and lowest priority item on the right. As you can see, it conveys the progress we have made so far on each MMF as well as what MMFs are complete vs. what MMFs are being worked on actively by the team.

If you see progress on right (lower priority MMFs), you should question why team is working on them. This might be legitimate, but you at least want to ask and get confirmation for a valid reason to work on lower priority items.

Another variation of this chart is to use percentage complete as shown in example below.


The previous chart (using SPs) gives you relative complexity that you can use to compare the effort involved among MMFs.

As I said, this chart is simple yet very effective. And, I am making it even more simple for you to create it. You can download a template and create this chart in just few clicks.

Business scenarios where I would use this chart:

• My director is asking for status on different slices of workin my project

• Why I see activity on the lowest priority MMFs

• What progress we are making, and on what pieces of the project

I have infact asked my directors to always have this chart handy. I recommend that all product owners carry this as well.

You should update it at end of every sprint. You want to share this with your stakeholders at the sprint review. And, also attach impediment list to this chart, especially when you are not making progress on some MMFs.

Light weight Documentation..

I used this software tool to complete documentation at one of the Client site I recently worked at. Rather than create long, boring MS Word documents, we created short Videos 'showing' how to complete certain tasks/activities. The software is available free of charge here.

The only catch with the free edition is that you can not create a video longer than 5 minutes. This limitation, though, works to your advantage as anything more than 5 minutes would get boring. This forces you to keep the video short, forcing you to pack more 'punch' within this 5 minutes.

This, obviously, does not replace the Word documents, but rather is an extension of Word documents and makes them 'light weight'. And, this tool makes the documentation process more fun!

Now onwards, enjoy the (dreaded) documentation!

Reading List..

I have been involved in transitioning two of the largest organizations (in the North America) to value driven project methodologies such as Agile, Scrum, and Lean. During these transitions, I have coached several teams, managers, and executives on Agile Practices and principles, and have often been asked for recommended reading list. I have accumulated a list of references that I often recommend my new teams read when starting their journey on Agile. Here is the list for your reference.

Books

Agile Project Management with Scrum (Schwaber)

User Stories Applied (Cohn)

Scrum and XP from the Trenches.pdf (Kniberg)

Scaling Software Agility (Leffingwell)

Agile Estimating and Planning (Cohn)

Implementing Lean Software Development: From Concept to Cash (Poppendieck)

Test Driven Development: By Example (Beck)

Agile Software Development with SCRUM (Schwaber)

Online References

Scrum Alliance

Being Agile is our favourite thing

Agile Manifesto

Agile Wikipedia

Mountain Goat Software

Jeff Sutherland NYC Spin

Scrum and XP from the Trenches

Agile Project Leadership

Agile Management

Ward Cunningham on the origin of the term Technical Debt

Agile Thoughts

Testers Shine on Agile Projects

Requirements Up Front

Agile Requirements

BSA Role

It’s Not Just Standing Up

Big Macs vs. The Naked Chef

Agile Has Crossed the Chasm

Constructive Disruption and Compromised Agility

Kanban in a nutshell

Learn from the experts: Blogs, RSS Feeds

Schwaber on Scrum

Agile Advice

Agile Alliance

Agile Management Blog

Implementing Scrum

Pages tagged with 'agile' on del.icio.us

Stevey's Blog Rants: Good Agile, Bad Agile

agile at google

The Planning Onion: Five Levels of Agile Planning

Shameless post: link to my blog

Unlearn what you have learnt

Delivering the W, One Game at a Time

Field of View

a quick introduction: What is Scrum?

Field of View..

Field of View is defined as the angular extent of the observable world that isseen at any givenmoment.

As we all know, in Agile, planning is a continuous process. We do not believe in big planning upfront; rather planning is a continuous process and we do planning at different layers, at different stages in the life of a project. Mike Cohn refers to these multi-layer planning as Planning Onion.

At different layers of this Planning Onion, the project team focuses on varying level of details at different stages of project.

At the inner most layer, the daily planning, team focuses on the particular day (What am I planning to do today? Are there any impediments?). So, at the inner most layer, we can say that our field of view is just that particular day, we focus on one day and thats about it.

The next layer is Sprint planning, often refered to as Iteration planning. The team is now expanding the full of view and now focusing on one iteration. Team's field of view is expanding from one day to couple of weeks (depending upon the length of the iteration.)

So as we move from the inner most layer to outer layers, the field of view is expanding. As you get to the inner layer the details become more and more clear.

If I put a flashlight in front of this planning onion, you will see that the light is brightest near the flash light at the inner most layers, and as we go the outer most layer the light becomes more and more dim, the details become hazy. So, with this flash light, you would still be able to see (kind of) the road map if you were looking far ahead but at the same time it would not give you lot of details.

Star Wars and Agile..

In the Star Wars movie The Empire Strikes Back, Luke tries unsuccessfully to rescue his X-wing fighter from the swamp. After some time, he gives up. He tells Jedi Master Yoda that lifting the fighter is impossible with the force, the new approach Yoda is trying to teach him. Yoda has these words of wisdom for him:

"You must unlearn what you have learned."

Scrum is no different! Like the Jedi force, the Scrum framework is conceptually easy; it's putting Scrum into practice that is difficult. In order for a team to be successful, the team members must unlearn what they have learned so far in their careers.

Check out my recent article for more details on what habits must be broken to succeed in Agile Adoption.

What is Scrum?

Recently, a friend of mine asked me "What is Scrum?"

I started thinking what is the best (and quickest) path to introduce a person to Scrum? So, I started my research for references; and here is a list of online resources that I feel can be used to get a quick familiarity with Scrum.

Enjoy!

Here are some more online resources:

• The Agile Elevator Speech
  
• Scrum in Five Minutes
  
• An Introduction to Scrum
  
• Scrum et al. - Ken Schwaber (who created Scrum) on Scrum at Google
• And, of course, if you are (American) football fan, you can read my article that draws similarity between The Partiots - a Football team and some of the Scrum practices.

Harvard Business Publishing and Agile..

I recently read an article from Harvard Business Publishing on "Why Good Projects Fail". As we all know, the failure rate for projects is very high; more than half of the projects fail! This is especially troublesome in Traditional Project Management as you would not know if the project is failing until it is too late (remember, one big bang delivery!)

In this Harvard Business Publishing, the author suggests using rapid-results initiatives in order to minimize and mitigate the risks of failure. What he means by that is "to use small projects designed to quickly delivery mini-versions of the big project's end results". Do you 'smell' Sprints here!?

He goes on to list several defining characteristics of this rapid-results initiatives approach such as:

* Results oriented (As we know, with each sprint, our goal is to deliver value to the Product Owner.)
* Vertical (Refers to Cross functional team)
* Fast (Refers to Sprints and Releases)

There are many parallels in this article and what we do in Agile landscape. Check out the article here to find out more details.