Key Quality Metrics

 In this blog we will discuss some of the key Quality Metrics.

Metric	Definition
Defect Leakage	It is the number of defects that is found by customers and NOT by the project team. Ideally it should be < 10%, however teams can strive for 5% or less as part of their optimizations.
Defect Injection Rate	The number of defects raised per day. If the trend is such that the number of defects identified are more at the beginning and it gradually reduces towards the end, it means that the project is in good health wrt quality.
Defect Density	The number of defects found in say a million lines of code Formula: Number of defects/LOC (in Million)
Code Coverage	The number of lines of code that the test case/suite covers as part of testing
Review Efficiency	The number of defects found during the review process. Either design review or code review etc Eg: Say, we need to find the review efficiency for detailed design document review: Formula = Number of defects found during DD review / (Number of defects found during DD review + Number of defects found in later stages of the project that has source as Detailed Design Phase) The above formula can also be extrapolated to Testing to obtain Test Efficiency. Eg: Test Efficiency for System Testing Phase = Number of Defects found in ST Phase / (Number of defects found in ST + SIT + UAT)
Defect Removal Efficiency	The number of defects resolved by the Dev team/Total number of defects raised.

Persuasion And Negotiation Techniques

 AS a Program Manager, one of the key task that we need to do is Stakeholder negotiation/persuasion. Not just Pgm Managers, colleagues in Sales can also be benefitted by this technique.

A couple of Techniques are discussed here.

1. Aristotle's Rhetoric
2. SPIN Technique

Aristotle's Rhetoric:

The study of persuasion began with the Greeks. They believed that rhetoric was very critical for a successful politician. A good rhetoric should be able to talk on both sides (which demonstrates that he/she knows the whole problem). It is also a great form of teaching. According to Aristotle there are 3 pillars that constitutes persuasion. They are:

1. Ethos (Credibility) - Increase the trust quotient with the help of your rank in the hierarchy, your knowledge in that area, your established relation in that group, any common ground between the listener and negotiator. (What do they share in common - their view points, beliefs etc)
2. Logos (Logic) - This should contain the facts of the argument. Any data, statistics, evidences, examples etc can be used as part of logos.
3. Pathos (Empathy) - Understanding the pain/concern and then emotionally connect - body language, tone etc

Persuasion is an art and understanding the pillars of it will help us carry the load of stakeholder management with ease, comfort and confidence.

SPIN Technique:

The below image from https://www.linkedin.com/pulse/spin-selling-techniques-sabyasachi-chakraborty/ will help us understand the SPIN technique very well.

Agile Best Practices

In this blog, I have tried to list down some of the Agile Best Practices that I had learnt in my experience.

Give sufficient time for grooming and estimation:

In my experience, especially with teams that are recently adapted to agile, it is very challenging for them to give an estimate during the 'Planning Poker' game. When I started a 'Pre Grooming' meeting, where the stories were discussed in detail and then gave a day's time for the team members to think about the estimation, the 'Grooming' meeting (now essentially an estimation meeting :)) became more meaningful 

Consider having product backlog refined upto atleast Sprint n+2:

The Product Owner must ensure he/she has the product backlog refined (stack ranked for the next 2 or 3 upcoming sprints). This helps the team to pick up the next stack ranked PBI even if the PO is unavailable due to sickness.

Calculate velocity as both Number of Storypoints and Number of Stories:

It is a good practice to note both the above metrics and follow the trend as your prediction for the upcoming sprint. The reason being, it gives a better predictability. How so?

For eg: Team 'A', who have just closed Sprint 'n' has a velocity with Sp = 40 and number of stories = 8. Sprint n+1, they choose 42 sp but the number of stories = 21. Is there a problem? The 40 sp are generated by Team A when they choose around 8 stories. Now if it gets tripled, chances are they would not meet 40 sp, because there is a heavy context switching associated with multiple stories, that would impact productivity of the team.

Calculate 'Value' delivered as a KPI:

While velocity as sp/stories, defect leakage, test coverage etc are good, scrum is all about delivering value. One of the six principles of scrum states 'Value based prioritization'. Therefore, we must consider measuring value delivered as a key metric. That's a good agile practice. How do we do that? Add the value for each story (ie) we would anyway stack rank the stories. To begin with add metric values like 10 for high value, 6 for medium and 3 for low value stories and mark the value for each story in the sprint. Measure it - we can do that easily through a Sprint Burn up chart. Track the value delivered sprint after sprint.

Remote Worker Engagement:

• Record Spring plan and review meetings (esp in case of scrum of scrum) and post the link in a common repository. That will help all team members to have an excellent point of reference.
• Have centralized status wikis that will pull the data from JIRA and present the details to all team members. Charts/2 D tables like Assignee Vs Defects, gives a view of all defects that are with that assignee. 
• Centralized wikis with 'Current Sprint+1' and 'Current Sprint + 2' backlog also will give an understanding of the upcoming work to the team members
• Conducting 'All Hands' once a month by the Leadership Team will ensure to bring the remote workers to the same platform and it is a great forum to understand program/portfolio/company level strategies, initiatives etc
• People Manager must have a monthly 1:1 with remote worker, if possible in a video call. This will help to increase the trust and there by team bonding.

Produce Matrix/Mapping where applicable:

If there are a number of permutations and combinations that should be tested (for eg), then if its applicable, we should try to create a matrix, that will help easier validation. Sample matrix/mapping that was created for UI validations.

Matrices Used in Program Management

There are multiple matrices that are used across programs that helps Program Managers assess the health of the program. In this blog, I have tried to capture various matrices that Pgm Managers use and a basic explanation and purpose of the same.

In this blog I have covered:

1. Risk Matrix
2. Stakeholder Interest Matrix
3. Work Prioritization Matrix
4. Stakeholder Expectation/Requirement Prioritization Matrix
5. Requirement Traceability Matrix
6. SWOT Analysis Matrix
7. Dependency Structure Matrix
8. RACI

Risk Matrix

This matrix helps to find the qualitative assessment of a risk. Based on this, the risk should be treated.

How to treat them?

If your risk falls on the green box, you can Accept the risk as the repercussions expected will be minimal.

If your risk falls on the red box, you can transfer the risk or avoid it 

If your risk falls on the yellow box, you can mitigate it (ie lower the impact or probability or both)

Stakeholder Matrix

This matrix helps us to understand where each Stakeholders are in the matrix. Based on their position in the matrix, we need to engage them appropriately.

This is an extremely useful matrix which helps the Program Manager to decide the level of communication required for each stakeholder.

Manage Closely: Mostly this will be the owner of the entire program. Has high stakes. Naturally Pgm Mgr has to manage him/her closely

Monitor: Most likely to be a sub contractor (non employee) whose involvement in the program would be for a limited time.

Keep Satisfied: This is most likely to be the executives or the program sponsors. Definitely they need to be satisfied with the program progress

Keep Informed: These are most likely to be architects or SMEs or ICs who has a lot of influence, but may have lesser influence on non technical decisions.

Work Prioritization Matrix

When we have conflicting priorities from multiple projects / multiple tasks, the below matrix will help us place the tasks in the appropriate division in the matrix, there by helping us to understand how to deal with those tasks.

Stakeholder Expectation/Requirement Prioritization Matrix

It is very common for Stakeholders/customers to come up with multiple requirements in a program. However based on the program goals and objectives, program managers should identify, in which of the below box, does the need of the stakeholder fall into. That will help the Pgm Manager to negotiate and also have a good and transparent relation with the stakeholder

Requirement Traceability Matrix

This matrix helps to trace, check and validate if all requirements are delivered. The requirement flows through multiple project phases - such as impact analysis, design, coding, testing. This matrix traces the requirement across all these phases to the final deliverable.

Why is this important:

1. Every requirement is mapped to the final deliverable. So it is easier to track the scope and completion.

2. When there is a future change in the requirement, the RTVM helps us to get all the records required from analysis to testing. Future changes are easier to implement.

3. Dependency between requirements can also be easily found using RTVM. If Req x is removed, the list of reqs that depend on Req X will also be impacted. These details can be found using RTVM.

Here is a sample RTVM. As you can see, the requirement is traced until Test. You can add impact analysis document, test case results too in the below.

SWOT Analysis Matrix

This is used to evaluate a company's position in the market to know where are positioned amongst its competitors. This can be used by company to come up with a strategy to improve their position in the market.

It can also be used by a person to understand his/her strengths and weakness

Dependency Structure Matrix

The dependency matrix is very useful to find dependencies across requirements or even stakeholder dependencies. For eg., in a task dependency matrix, both the rows and columns are tasks. Tasks in the rows are tasks that have dependencies on the tasks in the column

In a very large program, this becomes very useful in scheduling the tasks and also risk of the tasks due to the dependencies.

The below table is taken from https://project-management.com/dependency-structure-matrix-dsm/

RACI Matrix

The RACI matrix is helpful to decide the ownership and the separation of the duty for each task.

Accountable - Should be one person, who will take decisions, sign off on the task etc

Responsible - The person or persons doing the task

Consulted - The person who is generally consulted before beginning or before sign off of the task

Informed - Keep the person in loop on the progress of the task.