• Enter your email address to subscribe to this blog and receive notifications of new posts by email.

    Join 24 other followers

  • Archives

  • Advertisements

Key factor – compliance or outlier

Data Points in trends like normal distribution determine the compliance vs outliers.  In Agile product development it is interesting to see and analyze the compliance vs outliers.

Estimation : Planning poker method – all scrum team members take their call based on their experience and judgement. So the Scrum master / PO decides the estimate value by consensus not by majority. Here outliers have more weight and will be important factor.

Sprint Planning : Prioritizing of stories is a collaborative effort between PO and DEV team/ Here the factor deciding the call is a common shared goal. Not outliers.

Skill / role matrix : Whether DEV and TEST teams will do their DEV and TEST tasks only or involve themselves in multiple areas if they have free time. Again in this case,  it is a new habit, may be. It’s a combination of compliance and outliers.

Product acceptance criteria and Definition of done – Clearly compliance

Review and retrospective – mix of compliance and outliers.


Some key aspects in scrum


Product Acceptance criteria – understanding the stories requirement clearly and preparing the stories completion as per the criteria. Mostly Product owners decide these. Development needs to understand them.


Definition of done (DoD) is a set of checklists and ‘musts’ before the release of sprint / product. It covers the acceptance criteria too.  DoD is generally a guideline and remains the same during the sprint.

Necessary but not sufficient

Set of product acceptance criteria for all stories without considering the whole sprint release falls under this category. Larger picture is more important and valuable than the sum of individual stories



Scope gold plating is risky

Correct Approximation Vs costly accuracy.

Particularly in Agile development, the first release consisting of few sprints might want to ensure minimum viable product version is completely functional and helps the users with their requirements. It is better to package the MVP (minimum viable product) and encourage users on the existing functionalities usage and obtain feedback. Next upgraded release can accommodate the short fall if any of the previous version. This is much better than trying to build all the requirements and not quite able to test the optimum coverage of the scenarios. Tailoring scope to right size is approximation here. Trying to gold plate scope too much than necessary will not only make the product dysfunctional but also will create a lasting disappointment in the minds of users.

Let us use approximation correctly and not do gold plating of scope to ensure smooth launch of product versions.

CHATS (Changes Any Time Simplified)

Some thoughts on Gemba walks in IT industry.

Even though embracing and welcoming changes any time is a great concept in Agile, how many products / services have actually accommodated this?

Let us call this welcoming change any time as Changes Any Time (CHAT). There is a better effective way by ensuring the changes are not too much during development. This is more important especially at least for two sprints or so you should not change requirements. So that some stability is developed.  If the development team gets in touch with product team at customer side during requirement formation itself, it will be great. Joint Application Development (JAD) have been successfully used towards  this direction by IT companies. Here we take a step back  and involve even during product conceptualization with development / domain expertise from development teams to reduce or eliminate unwanted features getting in to the product backlog. Involving in scope development to arrive problem definition (Scope Driven Problem development) will simplify CHAT.  Then it becomes CHATS (Changes Any Time Simplified)

Build right product, right.

Building the product right follows building right product.

Since building right comes first, it would be better to start the product building at source. Yes right from customer perceiving the product theme,  software development organizations need to involve themselves. Quite possible that software organization vendors have been working with customer for long and understood their domain well. Also possible that there are some shifts in the customer organization at the senior levels / product domains. In this case software vendor would do well to suggest right features and good insights about the upcoming new products to them. The features, possible uses, user prospects et al can be some useful ideas that can come straight from vendors. This is cocreating right from problem space of product development.

Next phase of building it right will effectively follow by Agile development practices. This way Agile is extended beyond just the development areas toward wholesome product making.

System thinking is real product development.


Embrace Agility and empower people

Agility is enabling and empowering. Hierarchy is command and control.

Empowered teams enjoy their challenges at work. Commanded teams get demotivated and somehow try to show their work as efficient and resulting in local efficiencies. Local efficiencies mean less alignment to the links and interfaces and compromise the overall effectiveness of the organization Goals

Agility is inspect and adapt. Structure is following the pre defined plan.

Agile methods provide Quicker response to market conditions, demands and fluctuations and ensure all stakeholders in the supply chain are happy.  Product becomes useful immediately after the release in short delivery cycles. Customer participation in product development results in right product is developed in the right ways. Quicker time to market enhances returns on investment for all stakeholders.  Following predefined plan leaves the product development with too much processes that inhibits growth particularly in changing requirement scenarios.  These days there are hardly any innovative products that do not undergo changes frequently.

Embrace agility and empower the people

Definition of Done (DoD) and Returns on Investment (DoD)

Definition of Done (DoD) and Returns on Investment (DoD) :

DoD is a common acceptance criteria between vendor and customers on product requirements – functional, non functional and expectations. It includes cost, schedule and budget  (CSB) either directly or indirectly.  When we extend these DoDs beyond cost schedule and budget to analyze the benefits / returns over the investment, it completes the cycle of product development.

We can deduce returns on investment in product scenarios as meeting CSB and analyzing to what extent the returns have been realized.  All the elements of the supply chain form product development teams, senior management and customers should be able to see quantitative values clearly. Initially during first few sprints there will be difference between what software vendor thinks  and what customer perceives as value  over the realized. However as the maturity and agreement becomes closer between them, we get to see the ROI values agreement get closer to them. Some Factors like how many features developed vs used,  what are the priority features planned vs delivered and how the market received the initial versions of the product are some determinants of the realization of common values.