Author Archives: Kiron Bondale

About Kiron Bondale

Measurable business value can be realized through the successful initiation, prioritization, planning & execution of strategic projects. Striking a pragmatic, value-based balance between people, process & technology is a key to achieving success with Project Portfolio Management initiatives. Effective change management is crucial when trying to improve PPM or PM capabilities. Having been involved with multiple capability improvement initiatives, what I've learned is that "it's easy in theory, difficult in practice"! Continuous improvement of hard & soft skills gained by assisting organizations in the achievement of their business goals through the execution of the right projects in the right way is my ongoing mission.

What’s in YOUR sprint backlog?

The Scrum Guide states that a sprint backlog “is the set of Product Backlog items selected for the Sprint, plus a plan for delivering the product increment and realizing the Sprint Goal. The Sprint Backlog is a forecast by the Development Team about what functionality will be in the next Increment and the work needed to deliver that functionality into a “Done” Increment.

We expect to find requirements, enhancements and even fixes in the sprint backlog, but is that it?

Remember that one of the three pillars of Scrum and a key principle of most agile approaches is transparency. Meaningful, significant work should be visible to all as agile doesn’t encourage hidden factories. If we don’t surface all major work being done by the team, it is understandable that a Product Owner or other stakeholders might assume that there isn’t a lot of work being done in a sprint or that the team isn’t being productive.

We can separate work which is worth being made visible into three broad categories:

  • Work items which directly add customer value to the product. Features, requirements, enhancements and fixes fall into this bucket. Learning activities such as spikes would also qualify.
  • Work items which indirectly enable or are required for product delivery. Environment support, deployment management, regulatory documentation are examples of this category.
  • Work items which improve the delivery process. Improvement ideas from retrospectives are one type of such work item

By sizing, prioritizing and tracking work items across all three of these categories, a Product Owner and team will gain a complete understanding of what they expect to work on in a given sprint. This encourages healthy trade-off conversations during sprint planning and will help the team identify opportunities for improvement which might otherwise have been missed. For example, if some team members are spending significant effort in keeping build and test environments operational, the Product Owner or other stakeholders might be more inclined to understand why this is needed and what they can do to reduce that effort.

There is a fourth category which you may not want to include in the sprint backlog, and that’s the activities performed by the team which are completely unrelated to the product or project. This could be year end employee performance assessments, town hall meetings, operational work or (hopefully not!) even supporting another project. Assuming team members have some insights into how much of their availability over the next sprint will be consumed by this unrelated work, they should communicate that to the rest of the team during sprint planning to ensure a reasonable sprint commitment is made.

So, with thanks to Capital One, what’s in YOUR sprint backlog?


Categories: Agile, Project Management | Tags: | Leave a comment

Control partners should have skin in the game!

I finally completed reading Nassim Taleb‘s book Skin in the Game which I had written about in a recent article.

In that piece I had applied his principles when comparing the benefits of a product-centric orientation to the project-centric model which is still found in many organizations. But after finishing the book, I realized that there is a much more compelling example of the challenges experienced with risk asymmetry in many large organizations, namely with those staff who are responsible for developing the policies, standards and methods used by teams for delivering projects or products.

In small companies, how a product gets developed and delivered is usually defined by a “Big Brain” (e.g. a solution owner or similar role) or developed collaboratively by those actually building the solution. But as the size of the organization increases and stakes get higher, control partners emerge to influence not only what but how production occurs.

Where things get difficult is when these control partners do not experience first-hand the downside of their decisions.

For example, in some companies, project management standards are set by a centralized department such as a PMO. While some delivery roles such as program or project managers might report in to the same PMO, there are staff whose sole focus will be to define and maintain standards. As those staff are not in a project delivery role, even if they possess years of practical experience, as they won’t themselves have to use the templates and tools which they have developed, they don’t have true skin in the game. Delivery staff may complain to control partners about how onerous or non-value add specific practices are, but there is little direct impact to them.

There are a couple of ways to rectify this situation:

  • Serving in such control functions could be a rotational responsibility. After someone has spent a reasonable amount of time in a control role, they should be required to spend an equal amount of time in a delivery role. This will also help them better identify patterns and anti-patterns specific to a given context.
  • Introduce performance measures and incentives for control staff which are tied to the impacts created by their work as opposed to just the completion of this work. For example, quantifying the cost of control or conducting regular satisfaction surveys with delivery staff are two methods in which we could bring back skin in the game.

Method makers and framework formulators – practice what you preach!




Categories: Facilitating Organization Change, Process Peeves, Project Management | Tags: , , | Leave a comment

Kano and perception minus expectations

For many years, my personal e-mail signature has been a quote from David Maister’s book on professional service management: “Customer satisfaction = Perception – Expectations“. This formula simply but elegantly captures how we feel when our expectations are either exceeded (or the opposite) when acquiring a product or receiving a service.

The Kano model provides a theory for product development and customer satisfaction. In an earlier article, I tried to connect this model and project management, but having just experienced an example of how past experiences can impact expectations and perceptions, I felt a follow up piece on Kano was warranted.

As a refresher, Kano’s original model provided four broad categories for product features: Must-be, attractive, one-dimensional and indifferent. I will describe these and provide examples from the personal automotive industry.

  • Must-be attributes are sometimes referred to as hygiene factors as they must be part of a product or service but gold-plating won’t result in greater satisfaction. Seat belts on a car are one example of these.
  • Indifferent features are those which don’t positively or negatively impact customer satisfaction regardless of their presence or absence. Fuzzy dice hanging from the rear-view mirror would likely fall into this category for the majority of car owners.
  • One-dimensional attributes are those which demonstrate a linear relationship to customer satisfaction. Seating surfaces in a car are one example of these. While I will be happier having leather seats than cloth seats, I am not likely to be exponentially happier.
  • The final category is attractive which are often referred to as delighters. These are those attributes which are unexpected but will excite or delight a customer. Heated steering wheels for purchasers in colder climates were an example of these a couple of years back.

While this categorization is helpful and can be used to support product feature decision making, the theory also suggests that over time, attributes we used to find attractive become one-dimensional and might even drop into the must-be category.

I spent the past week relaxing at a Caribbean resort. This was my third trip to the same resort and a contributing factor in the decision to return a third time as well as the reason I had strongly promoted this resort to others was the magnitude of recognition I had been shown upon my second visit last year. This recognition far exceeded any expectations I might have had so the specific nature of the recognition clearly fell into the attractive category.

Given how far my perceptions had exceeded my expectations on my second visit you can understand why I would have similar expectations for a third visit. The attractive had now become a one-dimensional. Unfortunately, reality fell short of expectations and while my overall experience at the resort was pleasant, I still felt let down.

Past perceptions set expectations.

If you delight your customers once but fail to do so on subsequent transactions, don’t be surprised if they are dissatisfied with otherwise acceptable levels of service.

Categories: Project Management | Tags: , | 1 Comment

Create a free website or blog at

%d bloggers like this: