Just sat down over coffee this morning and read the most recent edition of Pragmatic Marketer’s Magazine titled ‘Death by Plan‘. In particular, I found the article on the 9 metrics to keep the team on track helpful given that I am on the middle of planning exercises as we look toward 2015. Definitely recommend reading the article itself, but here is a summary of the points with a few thoughts:

1. Stories Complete vs. Stories Committed – difficult to predict in the early days but important to keep track of nonetheless (especially if you are transitioning from waterfall and the team is still learning or hasn’t quite hit its stride). Having this perspective going into Sprint Planning will make the process more effective.

2. Technical Debt Mgmt – this is one that I personally have struggled with over the years. Every product has bugs or things that need to be adjusted that aren’t necessarily new features. Stack ranking these types of work items against revenue drivers doesn’t seem practical. Much like in the waterfall days, I prefer having an understanding of how much capacity with any given Sprint/Release should be dedicated to technical debt.

3. Team Velocity – goes hand in hand with point #1 in my mind towards efficiency and effectiveness in planning.

4. Quality Delivered – when I think about the context of delivering value to the customer, what immediately came to mind was the definition of ‘done’. The article spoke about this under a different point, but just because you are code complete that doesn’t necessarily equate to ‘done’. Make sure you have agreement on expectations up front!

5. Team Enthusiasm – pretty straight forward.

6. Retrospective Process Improvement – continuous improvement is always a good idea … what went well, what didn’t, what easy adjustments can be made vs. longer term changes, etc.

7. Communication – fairly straight forward, unless the team is located in multiple offices/geographies and then it can be challenging. DO NOT solely rely on email for communication, and brace yourself with the understanding that there will be times where your job description reads babysitter, mediator, peacekeeper, etc.

8. Adherence to Best Practices – being Agile does not imply that anything goes, or that standard operational processes should be bypassed. For example, If an existing process for capturing production issues is in place across the broader context of the organization, it may not be a good idea to come up with your own.

9. Understanding of Sprint Scope and Goal – this one is squarely on us as product managers. If you can’t articulate the ‘what’ or the ‘why’ in clear business terms, you can’t expect the team to magically come up with the ‘how’.