Course Discount

Search

What Does Metrics Mean For Agile Teams

Most of the places I have worked, I spent a lot of time in measuring multiple dimensions of software for the entire lifecycle of the product. Many try to see what is the “best practice” in the industry and put a wrapper on them to make their own metrics. I have been thinking for a while on what makes sense, and is there a silver bullet like the Grand Unified Theory. While at it, it looks to me that we are trying to contain ourselves in one direction in as chaotic as a place of Software Product Development. Organizations tend to copy “what worked for them” without even caring for the constraints and conditions that the specific metric worked for “them”. Then, what to measure? In my view, organizations which have understood what and how much to measure a products usefulness, have survived and thrived. These have eventually emerged as the Agile organizations. When they have multiple products, they have different lenses for each of them as well. Some products will need a lot of statistics and data while some may need only a few! And, how do you arrive at what to measure? For me the closest guide is 7th principle from Agile Manifesto “Working software is the primary measure of progress”. If you can define what is the working software for you, it becomes easier to measure the progress. Again, each one in their role, see the “working software” in a different way. Hence it becomes very important to have a holistic view of who is the customer, who is the builder, who is the sponsor and who manages the process. Let us try to think from each perspective.  Note: These thoughts for building a product or service should only serve as a starting point and none of them are given in any order of preference. “The best architectures, requirements, and designs emerge from self-organizing teams” and so does the metrics and measurement.  Before proceeding to a detailed discussion on the metrics for product owners, investors and developers, let us quickly go through the essential Scrum metrics. Business/Product Owner/Product Manager In a functional Agile team, this role is primarily responsible for understanding the market and synthesizing the data. They have “Hypothesis” around what makes the organization profitable. When all they are working with is a hypothesis and not much of clarity, they will be interested in forward looking metrics. The following could be the measures they need: 1. Cost of Delay: Cost of Delay is "a way of communicating the impact of time on the outcomes we hope to achieve". More formally, it is the total expected value with respect to time. Cost of Delay combines an understanding of value with how that value leaks away over time. It is the answer to the question: "What would it cost us if this was delayed by 1 month?". Or, alternatively, "what would it be worth to us if we could get this 1 month earlier?" 2. Product Market Fit : Product/market fit is the degree to which a product satisfies a strong market demand. Product/market fit is the first step to building a successful venture in which the company meets early adopters, gathers feedback and gauges interest in its product(s). 3. Riskiest Assumption Test (RAT): A Riskiest Assumption Test is explicit. There is no need to build more than what’s required to test your largest unknown. No expectation of perfect code or design.  4. Minimum Viable Product (MVP): The version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort. It is a product with just enough features to satisfy early customers, and to provide feedback for future product development. 5. Minimum Marketable Product (MMP):  MMP is based on the idea that less is more. It describes the product with the smallest possible feature set that addresses the needs of the initial users (innovators and early adopters), and can hence be marketed and/or sold. The MMP is a tool to reduce time-to-market: It can be launched more quickly than a fat, feature-rich one. 6. Cycle Time:  Cycle time is the total time from the beginning to the end of your process, as defined by you and your customer. Cycle time includes process time, during which a unit is acted upon to bring it closer to an output, and delay time, during which a unit of work is spent waiting to take the next action.   The “Product” group should have a mechanism to understand and keep an eye on the metrics that are important to Sponsors/Investors as well. This will make sure the loop is closed and any suggestion to “Pivot” is indicated by them.    Sponsor/Investor  Interestingly, this group has interest in the same metrics that are used by Business/Product Managers before the product is launched. I am inclined to use thoughts from “lean start-up” as they are more “actionable” and not “vanity metrics”. During and after the product launch, the following are the measurement/information they will be most interested in: 1. Employee Satisfaction: Happier and motivated employees make sure they keep the customer happy and engaged. Employee satisfaction is the terminology used to describe whether employees are happy and fulfilling their desires and needs at work. Employee satisfaction is a factor in employee motivation, employee goal achievement, and positive employee morale in the workplace. 2. Viral coefficient: A viral coefficient is a number which tells you how many customers each is your present customer bringing to you on an average. So this means if your viral coefficient is 2 then each of your current customer is bringing in 2 customers to your business. This metric calculates the exponential referral cycle, sometimes called virality, that accelerates company growth. Virality is the inherent incentive for customers to refer friends or colleagues to your company. 3. Sunk Costs: In economics and business decision-making, a sunk cost is a cost that has already been incurred and cannot be recovered. Sunk costs (also known as retrospective costs) are sometimes contrasted with prospective costs, which are future costs that may be incurred or changed if an action is taken. 4. Viral Cycle Time: Viral cycle time is the time it takes for one such cycle to complete. In other words, viral cycle time is the amount of time it takes for a user to invite another user. 5. Net Promoter Score: Net Promoter or Net Promoter Score (NPS) is a management tool that can be used to gauge the loyalty of a firm's customer relationships. It serves as an alternative to traditional customer satisfaction research and claims to be correlated with revenue growth.  The Net Promoter Score is calculated based on responses to a single question: How likely is it that you would recommend our company/product/service to a friend or colleague? The scoring for this answer is most often based on a 0 to 10 scale. Those who respond with a score of 9 to 10 are called Promoters. Those who respond with a score of 0 to 6 are labelled Detractors. Responses of 7 and 8 are labelled Passives, and their behavior falls in the middle of Promoters and Detractors. The Net Promoter Score is calculated by subtracting the percentage of customers who are Detractors from the percentage of customers who are Promoters. For purposes of calculating a Net Promoter Score, Passives count towards the total number of respondents, thus decreasing the percentage of detractors and promoters and pushing the net score towards 0. 6. Customer Happiness Index (CHI): Instead of using NPS, the organization could also create a Customer Happiness Index of its own including the parameters it wants to measure. This approach has a benefit, as the organization has to “talk to the customer” and can understand the parameters that are necessary for its context. 7. % Paying Customers: Understanding the demography of how many people are using the paid product/services in the overall customer base helps us to understand the market better. 8. Conversion Rate: The gist of the funnel is that you start with people who are suspects, who then convert to prospects then convert leads which convert into sales. The percent conversion at each step is calculated. The overall conversion rate of a sales funnel is determined by taking the number of sales divided by number of suspects times 100. 9. Customer Acquisition Cost (CAC):  CAC can be calculated by simply dividing all the costs spent on acquiring more customers (marketing expenses) by the number of customers acquired in the period the money was spent. For example, if a company spent $100 on marketing in a year and acquired 100 customers in the same year, their CAC is $1.00. 10. Customer Stickiness: Customer stickiness is the increased chance to utilize the same product or service that was bought in the last time period.  Developer/Builder Sadly, we try to measure everything here. While the measures and metrics here give you an indication of “are we building it right?”, it doesn’t guarantee “are we building the right thing”. It is vital for a developers to know the metric they are getting along with having a view of all other metrics we talked about till now. The metric we use here, should always supplement the metrics that we talked about. This is something the Agile methodologies have rightly incorporated.  This group is technology oriented and hence, the metrics are more technical in nature as well.  Some of the metrics that could help understanding “building it right” are: 1. Health of CI/CD pipeline: Are the builds happening right? Are they fast enough for the teams to experiment often?  2. Number of Green builds per day/week : Discipline within the team, so as to get code checked in daily, and builds are made often. The team can work in small batches as they know that the last logical piece of code they have submitted is working.   3. % of green builds : To continue, not just the number of builds are important, but also how many of them were good. A good developer doesn’t want others to be stuck because of him/her. 4. Unit Test Coverage: Adherence to Agile Test Pyramid is the only way to be in the fast zone of Product Development. The Unit Tests should comprise ~80% of all tests and an essential part of building the quality-in.  5. Code Coverage: Code coverage is a term to describe which application code is exercised when the application is running. Measuring code coverage is a technique for understanding exactly which application code is being exercised.  6. Non-Functional Test Coverage: It is essential to understand the non-functional requirements, called often as “ility tests” (usability, accessibility, reliability etc.) as they help in understanding what the customers or market don’t explicitly ask for.  7. Benchmarking of NFR’s: Benchmarking is an important part of understanding where we can reach. It could be against customer wishes or against industry standards. When we understand the current measures, we can aim/plan or negotiate the future measures. 8. Defects found per unit of Unit/Functional/Integration Test: While the number of defects might not indicate anything substantial, they do slow us down in building. If we can find a pattern or the magnitude, planning for releases becomes easy and market commitments live their date. 9. Number of defects per feature from Production/UAT/Customer: Feature is what customers pay for in most cases. Understanding the important features and making sure they are built with quality makes developers and builders of the system to concentrate more on where it matters.  10.Defects that can be lived with: Not all defects kill you! Pay attention to the most important ones and spend as less time as possible with the other ones. When delivering often is the necessity for a system/product/service, perfection is not always an answer and asked for as well.  11. Rework: Unknowingly we spend a lot of time on rework, which can well be utilized for the “work”. Practices like Split-testing, Pair Work (E.g. : Dev-Test, Test-Documentation etc. working in pair), having separate environments, testing and fixing with Developer can help the teams avoid the cost of late defect fixes.  Customer/User The person for whom we are building a solution is also a part of the system. The customers may or may not understand any of the numbers, measurements and metrics. They want their problems to be solved in a simplistic way, without learning too many things in the process. We should not be adding more stress to them. The organizations or entrepreneurs who understand the above statement and work towards that will succeed and thrive!!! Five #agile metrics you won't hate... and the anti-patterns to watch for: https://t.co/FkaX8fmZoR pic.twitter.com/8Xs3mYdrRg — Atlassian Jira (@Jira) December 28, 2015   Summary We may or may not be able to demarcate different roles as I have done here in the real world. Care has to be taken to understand “what”, “when” and “how much” to measure depending on the circumstances a product/service works. Most of the measures talked about links us back to the customer and it is thoroughly essential that we take that view from the first step we take towards building a product or service.   
Rated 3.0/5 based on 4 customer reviews

What Does Metrics Mean For Agile Teams

746
What Does Metrics Mean For Agile Teams

Most of the places I have worked, I spent a lot of time in measuring multiple dimensions of software for the entire lifecycle of the product. Many try to see what is the “best practice” in the industry and put a wrapper on them to make their own metrics. I have been thinking for a while on what makes sense, and is there a silver bullet like the Grand Unified Theory.

While at it, it looks to me that we are trying to contain ourselves in one direction in as chaotic as a place of Software Product Development. Organizations tend to copy “what worked for them” without even caring for the constraints and conditions that the specific metric worked for “them”.

Then, what to measure? In my view, organizations which have understood what and how much to measure a products usefulness, have survived and thrived. These have eventually emerged as the Agile organizations. When they have multiple products, they have different lenses for each of them as well. Some products will need a lot of statistics and data while some may need only a few!

And, how do you arrive at what to measure? For me the closest guide is 7th principle from Agile Manifesto “Working software is the primary measure of progress”. If you can define what is the working software for you, it becomes easier to measure the progress.

Again, each one in their role, see the “working software” in a different way. Hence it becomes very important to have a holistic view of who is the customer, who is the builder, who is the sponsor and who manages the process. Let us try to think from each perspective. 

Note: These thoughts for building a product or service should only serve as a starting point and none of them are given in any order of preference. “The best architectures, requirements, and designs emerge from self-organizing teams” and so does the metrics and measurement. 

Before proceeding to a detailed discussion on the metrics for product owners, investors and developers, let us quickly go through the essential Scrum metrics.

Business/Product Owner/Product Manager

In a functional Agile team, this role is primarily responsible for understanding the market and synthesizing the data. They have “Hypothesis” around what makes the organization profitable. When all they are working with is a hypothesis and not much of clarity, they will be interested in forward looking metrics. The following could be the measures they need:

1. Cost of Delay: Cost of Delay is "a way of communicating the impact of time on the outcomes we hope to achieve". More formally, it is the total expected value with respect to time. Cost of Delay combines an understanding of value with how that value leaks away over time.

It is the answer to the question: "What would it cost us if this was delayed by 1 month?". Or, alternatively, "what would it be worth to us if we could get this 1 month earlier?"

2. Product Market Fit : Product/market fit is the degree to which a product satisfies a strong market demand. Product/market fit is the first step to building a successful venture in which the company meets early adopters, gathers feedback and gauges interest in its product(s).

3. Riskiest Assumption Test (RAT): A Riskiest Assumption Test is explicit. There is no need to build more than what’s required to test your largest unknown. No expectation of perfect code or design. 

4. Minimum Viable Product (MVP): The version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort. It is a product with just enough features to satisfy early customers, and to provide feedback for future product development.

5. Minimum Marketable Product (MMP):  MMP is based on the idea that less is more. It describes the product with the smallest possible feature set that addresses the needs of the initial users (innovators and early adopters), and can hence be marketed and/or sold. The MMP is a tool to reduce time-to-market: It can be launched more quickly than a fat, feature-rich one.

6. Cycle Time:  Cycle time is the total time from the beginning to the end of your process, as defined by you and your customer. Cycle time includes process time, during which a unit is acted upon to bring it closer to an output, and delay time, during which a unit of work is spent waiting to take the next action.
 
The “Product” group should have a mechanism to understand and keep an eye on the metrics that are important to Sponsors/Investors as well. This will make sure the loop is closed and any suggestion to “Pivot” is indicated by them.   

Sponsor/Investor 

Interestingly, this group has interest in the same metrics that are used by Business/Product Managers before the product is launched. I am inclined to use thoughts from “lean start-up” as they are more “actionable” and not “vanity metrics”. During and after the product launch, the following are the measurement/information they will be most interested in:

1. Employee Satisfaction: Happier and motivated employees make sure they keep the customer happy and engaged. Employee satisfaction is the terminology used to describe whether employees are happy and fulfilling their desires and needs at work. Employee satisfaction is a factor in employee motivation, employee goal achievement, and positive employee morale in the workplace.

2. Viral coefficient: A viral coefficient is a number which tells you how many customers each is your present customer bringing to you on an average. So this means if your viral coefficient is 2 then each of your current customer is bringing in 2 customers to your business. This metric calculates the exponential referral cycle, sometimes called virality, that accelerates company growth. Virality is the inherent incentive for customers to refer friends or colleagues to your company.

3. Sunk Costs: In economics and business decision-making, a sunk cost is a cost that has already been incurred and cannot be recovered. Sunk costs (also known as retrospective costs) are sometimes contrasted with prospective costs, which are future costs that may be incurred or changed if an action is taken.

4. Viral Cycle Time: Viral cycle time is the time it takes for one such cycle to complete. In other words, viral cycle time is the amount of time it takes for a user to invite another user.

5. Net Promoter Score: Net Promoter or Net Promoter Score (NPS) is a management tool that can be used to gauge the loyalty of a firm's customer relationships. It serves as an alternative to traditional customer satisfaction research and claims to be correlated with revenue growth. 

The Net Promoter Score is calculated based on responses to a single question: How likely is it that you would recommend our company/product/service to a friend or colleague? The scoring for this answer is most often based on a 0 to 10 scale.

Those who respond with a score of 9 to 10 are called Promoters. Those who respond with a score of 0 to 6 are labelled Detractors. Responses of 7 and 8 are labelled Passives, and their behavior falls in the middle of Promoters and Detractors. The Net Promoter Score is calculated by subtracting the percentage of customers who are Detractors from the percentage of customers who are Promoters. For purposes of calculating a Net Promoter Score, Passives count towards the total number of respondents, thus decreasing the percentage of detractors and promoters and pushing the net score towards 0.

6. Customer Happiness Index (CHI): Instead of using NPS, the organization could also create a Customer Happiness Index of its own including the parameters it wants to measure. This approach has a benefit, as the organization has to “talk to the customer” and can understand the parameters that are necessary for its context.

7. % Paying Customers: Understanding the demography of how many people are using the paid product/services in the overall customer base helps us to understand the market better.

8. Conversion Rate: The gist of the funnel is that you start with people who are suspects, who then convert to prospects then convert leads which convert into sales. The percent conversion at each step is calculated. The overall conversion rate of a sales funnel is determined by taking the number of sales divided by number of suspects times 100.

9. Customer Acquisition Cost (CAC):  CAC can be calculated by simply dividing all the costs spent on acquiring more customers (marketing expenses) by the number of customers acquired in the period the money was spent. For example, if a company spent $100 on marketing in a year and acquired 100 customers in the same year, their CAC is $1.00.

10. Customer Stickiness: Customer stickiness is the increased chance to utilize the same product or service that was bought in the last time period. 

Developer/Builder

Sadly, we try to measure everything here. While the measures and metrics here give you an indication of “are we building it right?”, it doesn’t guarantee “are we building the right thing”. It is vital for a developers to know the metric they are getting along with having a view of all other metrics we talked about till now. The metric we use here, should always supplement the metrics that we talked about. This is something the Agile methodologies have rightly incorporated. 

This group is technology oriented and hence, the metrics are more technical in nature as well. 

Some of the metrics that could help understanding “building it right” are:

1. Health of CI/CD pipeline: Are the builds happening right? Are they fast enough for the teams to experiment often? 

2. Number of Green builds per day/week : Discipline within the team, so as to get code checked in daily, and builds are made often. The team can work in small batches as they know that the last logical piece of code they have submitted is working.  

3. % of green builds : To continue, not just the number of builds are important, but also how many of them were good. A good developer doesn’t want others to be stuck because of him/her.

4. Unit Test Coverage: Adherence to Agile Test Pyramid is the only way to be in the fast zone of Product Development. The Unit Tests should comprise ~80% of all tests and an essential part of building the quality-in. 

5. Code Coverage: Code coverage is a term to describe which application code is exercised when the application is running. Measuring code coverage is a technique for understanding exactly which application code is being exercised. 

6. Non-Functional Test Coverage: It is essential to understand the non-functional requirements, called often as “ility tests” (usability, accessibility, reliability etc.) as they help in understanding what the customers or market don’t explicitly ask for. 

7. Benchmarking of NFR’s: Benchmarking is an important part of understanding where we can reach. It could be against customer wishes or against industry standards. When we understand the current measures, we can aim/plan or negotiate the future measures.

8. Defects found per unit of Unit/Functional/Integration Test: While the number of defects might not indicate anything substantial, they do slow us down in building. If we can find a pattern or the magnitude, planning for releases becomes easy and market commitments live their date.

9. Number of defects per feature from Production/UAT/Customer: Feature is what customers pay for in most cases. Understanding the important features and making sure they are built with quality makes developers and builders of the system to concentrate more on where it matters. 

10.Defects that can be lived with: Not all defects kill you! Pay attention to the most important ones and spend as less time as possible with the other ones. When delivering often is the necessity for a system/product/service, perfection is not always an answer and asked for as well. 

11. Rework: Unknowingly we spend a lot of time on rework, which can well be utilized for the “work”. Practices like Split-testing, Pair Work (E.g. : Dev-Test, Test-Documentation etc. working in pair), having separate environments, testing and fixing with Developer can help the teams avoid the cost of late defect fixes. 

Customer/User
The person for whom we are building a solution is also a part of the system. The customers may or may not understand any of the numbers, measurements and metrics. They want their problems to be solved in a simplistic way, without learning too many things in the process. We should not be adding more stress to them.
The organizations or entrepreneurs who understand the above statement and work towards that will succeed and thrive!!!

 

Summary

We may or may not be able to demarcate different roles as I have done here in the real world. Care has to be taken to understand “what”, “when” and “how much” to measure depending on the circumstances a product/service works. Most of the measures talked about links us back to the customer and it is thoroughly essential that we take that view from the first step we take towards building a product or service. 
 

Ashwinee

Ashwinee Kalkura

Blog Author

Ashwinee Kalkura's qualifications include SPC4, PMP, CSM, CSP, SA, SASM, SSM, ICP-ACC and SSGB professional certifications. He has a progressive experience of 16 years in Networking, Mobile and Retail industry and multiple methodologies. Ashwinee is currently working as Head of Agile & SAFe consulting at KnowledgeHut. He has delivered SAFe training for 450+ candidates in APAC region.

Join the Discussion

Your email address will not be published. Required fields are marked *

Suggested Blogs

How Does an Agile Mindset Pave the Way for Professional Success?

In the days before the advent of Agile, most large organizations were run with a bureaucratic mindset. Even as Agile has taken over the world of work today, a large number of professionals and organizations are yet to embrace the Agile mindset as they are stuck in the traditional paradigm.  Traditionally, the primary focus of managers in a top-down hierarchy has been on bringing in funds for the organization and its investors, even as they are sorting out work in line with the rules, jobs, and criteria that have been pre-determined. The existence of a bureaucratic mindset, therefore, promotes hierarchy over collaboration. When the workforce has a bureaucratic attitude, the productivity at an organizational level gets impeded. This is especially the case in situations that are subject to rapid changes concerning business needs,opportunities, or challenges.. What is an Agile mindset? An Agile mindset is a mentality of having a positive, feedback-based,and flexible perspective. This mindset places high regard on mutual respect, collaboration, improvement, iterative construction, and learning cycles.It takes pride in ownership, lays focus on delivering value, and has the inherent ability to adapt to change. An agile mindset is critical to cultivating high-performing teams, capable of delivering amazing value for their customers. The Characteristic Traits of An Agile Mindset An agile mindset can be identified by certain behavioral traits. These are applicable at the level of an individual, team, and enterprise at large.  High degree of collaborative efforts: Teamwork is crucial to foster an Agile mindset. Those who wish to cultivate this mindset should have a thorough understanding of objectives, deliverables, and ownership. Tolerance, mutual respect, and a team-player’s attitude are essential for effective collaboration. Self-motivated: A certain sense of motivation will be displayed by professionals having this mindset. They are often driven enough to execute tasks until completion and even develop better strategies to perform tasks. Self-motivated teams are empowered teams as they are capable of driving success with their efforts while taking responsibility for their actions at the same time. Customer-focused and outcome-driven: Delivering value to customers within the stipulated deadlines and budget is second nature to those with an Agile mindset. Customer’s needs are top priority and an outcome-based approach will be followed to meet them.Speed and Transparency: A quick turnaround time is a hallmark of Agile environments. Work is often done in small increments over time while the feedback loops are shortened to boost progress and reduce errors. Transparency is a trait that every member of the team should possess so that work can be entrusted to them without a second thought. Getting Ahead with An Agile Mindset  A significant aspect of having an Agile mindset is an individual’s willingness to remain unfazed in failure, yet open to learning and growing to prevent the same mistakes. As a professional in the dynamic digital age, one has no option but to embrace changes.  With new technologies, work processes and customer demands emerging daily, cultivating an Agile mindset has become imperative for professional growth. Farsighted organizations have already embarked on their Agile journeys, with 92% senior executives globally believing that organizational agility is critical to business success.  This calls for the need of an Agile workforce and translates into greater opportunities for skilled professionals with an Agile mindset.The true adoption of the Agile mindset cannot happen over-night, it takes a gradual shift in perspectives which will eventually guarantee lasting returns.Attending workshops led by Agile experts is a great way to get started with one’s journey towards developing an Agile mindset. Not only will it help shape one’s mindset but also open doors to exciting opportunities in Agile. 
Rated 4.5/5 based on 0 customer reviews
How Does an Agile Mindset Pave the Way for Profess...

In the days before the advent of Agile, most large... Read More

Scrum Product Backlog and Agile Product Backlog Prioritization

The 21st century has witnessed a major surge in the adoption of Agile with organizations trying to fit into their ways of working to better meet customer demands. As per the 14th Annual State of Agile 2020, 58% of the respondents were using Scrum as the framework for product delivery. It has been noticed that Agile and Scrum are considered as the same thing. Scrum is a subset of Agile where Agile is a way or method of implementing frameworks like Scrum, Kanban, etc. Agile is a timeboxed, iterative way of software delivery focusing on faster time to market and customer collaboration. With a great framework like Scrum, Agile gets a runway to deliver quality products in an iterative, incremental, and timeboxed manner. Talking of product development, be it any framework, we start with the creation of the requirement list. The same applies to Agile too. Here, we term this as “Backlog”. I am often asked about the origin of the term, “Backlog”. Why “backlog” and why not some other word? Well, the term dates back to the 1680s when large logs were placed at the back of a fire to keep the blaze going and concentrate the heat. By the 1880s, the term was adopted in its figurative sense of "something stored up for later use". So, a Backlog is a prioritized list of items the teams’ need to work for the successful delivery of a product. According to the State of Scrum 2015 report, surprisingly, only 56% of the respondents reported using extensive scrum artifacts like Product Backlog and Sprint Backlog. Major success criteria for any Agile project lie in its backlog and it demands a lot of focus both in terms of keeping it refined and updated with current situation. Thankfully, it is the topic of the day, and here we will talk more about it! Product Backlog  What is a Product Backlog? The Product Backlog is the ordered list of requirements of all that is required to successfully deliver it to the client. It contains the prioritized list of requirements that can be detailed or vague and has everything that needs to be done for a particular product. One can visualize it as a big bucket that has all the items/necessities needed for a product to be successful and competitive in nature.  Who owns the Product Backlog? The Product Backlog is primarily handled by the Product Owner who takes care of the client's needs and makes sure the product backlog represents the exact requirement. The product owner is responsible for keeping the backlog healthy and in a state that is readily consumable by the team. The product backlog is never frozen, the items can change as per the demand and market scenario. Anyone can suggest items to be added in the list but the final say will always be on the Product Owner.  Example of a Product Backlog Let’s look at an example to further understand it better: Build a mobile application for a local bank so that the users can access the bank on the go. Product Backlog would look like: S. No.RequirementPriority1Create a sign in page for the usersHigh2Create a logout pageHigh3Create a home page to land after successful sign in to the applicationHigh4Create a page for AccountsMedium5Create a page for Money TransferMedium6Create a page for LoansMedium7Create a page for User ProfileLow8Create a page for 'Contact Us' sectionLowThere can be multiple other requirements both frontend and backend to get this mobile application delivered, but, here for understanding, we are just taking a few of them. Each item in the list will have a priority attached to it, this makes it easy for the development team to pick work once they are done with the one in hand. Product Backlog can also be termed as the master list of requirements. Sprint Backlog What is a Sprint Backlog? Sprint Backlog is a list derived from the product backlog or the master list. When teams start working in Scrum, they have sprints which are a timebox for delivery, it defines when a customer can expect the shipment and at what intervals. The period can range from a week to a months’ timeline. Here, in sprints, the team pulls the work from the product backlog as per the priority and their capacity and put it in a smaller bucket called ‘Sprint Backlog’. It is like delivering the big Product Backlog in chunks called “Sprint Backlog’. The Sprint Backlog can also be defined as a subset of superset ‘Product Backlog’. For a successful product delivery, both are essential, and hence the need to keep them healthy.  Who owns the Sprint Backlog? Sprint backlog is owned by the scrum team andtogether they create their sprint board which consists of the user stories, bugs (if any), and spikes. It is the development team who determines the Sprint Backlog. Here, the Scrum Master can facilitate the Sprint Planning meeting to help the team come up with the Sprint Backlog. The scrum team utilizes the sprint planning meeting to discuss on the sprint goal and the commitment they can make for the upcoming sprint. They pull the items to discuss from the top of the list and create their sprint backlog according to the capacity and complexity of parameters.  Example of a Sprint Backlog So, the sprint backlog is a subset of product backlog and going back to our example let's create a Sprint backlog now: S.No.RequirementPriority1Create a sign in page for the usersHigh2Create a logout pageHigh3Create a home page to land after successful sign-in to the applicationHighIn our example, we have pulled the sprint backlog items from the master list which was already in a prioritized state. Product backlog vs Scrum backlog: Understanding the difference The Scrum Master can help the development team understand the difference between Product Backlog and the Sprint Backlog, this can be done through coaching the teams about the process and the Scrum artifacts and can help the Product owner in maintaining a healthy backlog. The team uses Product Backlog to create their sprint backlog. During the Sprint planning meeting, the development team should talk about the complexity and the efforts needed to get the job done. They pull the items from the product backlog to the Sprint Backlog to be completed in the sprint timebox. How to create a more effective Product Backlog? Effective Product Backlog depends on a clear understanding of the result and the need. The Product Owner must clearly define the requirements that have details enough for the team to get a clear picture of what is needed to be done. The product backlog needs to be a thorough list of all the work that must be done to get the project delivered successfully. Once a high-level list is created, the development team can help in further refining and creating an exhaustive backlog with all the technical aspects needed to deliver the functional side. Creating a backlog should be a collective team effort, this also helps in bringing about the ownership and collaborative environment amongst the group. Though the development team can help the Product Owner in creating a proper efficient Product Backlog, the sole responsibility for the Product Backlog lies with the Product Owner. How to create a better Sprint Backlog? Once you have a good Product Backlog, pulling out the Sprint Backlog gets easy. Sprint Backlog gets its shape during the sprint planning meeting which is the first thing in a new iteration where the team sits together, either, physically or virtually, to discuss the requirements they can work on in a new sprint. Essentially the discussion circles the functionalities, the technical aspect around it, and how much they can load in an iteration. Here, the Scrum Master can help the team with excellent facilitation skills to come up with a sprint goal as a joint team effort. The team pulls up the highest priority items from the product backlog to discuss functionality and complexity, they also converse on the steps they could take to reach the goal. What are the benefits of Backlog Prioritization? Prioritization is one of the critical aspects of a Product Backlog that helps in keeping it in a healthy state. Let’s look at a few of the benefits of prioritizing the backlog: Helps in the Sprint Planning with the story selection as the Product Backlog is already Prioritized. Better visibility to pull items during the iteration if the team has the bandwidth. Effective risk management due to pre-known issues during the grooming of the backlog Improved supervision of dependencies Early return of investment as the requirement follows value-based delivery. What are the different prioritization techniques or methods of prioritizing the Backlog? After talking about the Backlog and its benefits, let’s look at the various techniques of prioritization: Tool 1:MoSCoW Method – Developed by Dai Clegg, this is the most widely used model while prioritizing the backlog. The name itself has the meaning - Must Have, Should Have, Could Have, and Won’t Have.  Tool 2: Kano Model - In the 1980s Kano Model was developed by Professor Noriaki Kano. Under the Kano Model, items are categorized according to the requirements and opportunities of the stakeholders. The categories are – ‘Basic expectations’, ‘Satisfiers’, ‘Delighters’.Tool 3: Stack Ranking – During Stack Ranking the items are placed in the order of priority which starts with one and goes up to the number of items in the backlog. Tool 4: Cost Of Delay – To measure the cost of delay one needs to understand: “What will be the cost per time unit if we delayed delivery?” This is difficult to measure sometimes if you don’t use the correct parameters. This figure states how much money every month it will cost your organization to delay the delivery of the finished project. In practical life, we all have experienced ‘cost of delay’ whether it is starting late for work or starting up late with a new assignment.  Conclusion Finally, we understand that both Product Backlog and Sprint Backlog are different entities tied together to the same group. It plays a crucial role in software delivery and helps the team deliver efficient solutions through effective backlog management tools and techniques. If the teams understand and use their backlog in a desired way, they can help the customers and the management in better delivery and gaining of new opportunities. 
Rated 4.0/5 based on 11 customer reviews
7622
Scrum Product Backlog and Agile Product Backlog Pr...

The 21st century has witnessed a major surge in th... Read More

Scrum Master Job Descriptions and Responsibilities In Agile

Scrum stands out as one of the most dominant Agile frameworks used widely across the world. As per the ‘14th Annual State of Agile Report’ published by VersionOne, Scrum has 58% of the segment in the overall adoption of frameworks across the organizations globally. Not only has Scrum captured a large share in the industry, it is also easy to implement and brings about a more collaborative approach.   Scrum has three roles: product owner, scrum master and the development team members. It is these three roles that define the way a team works towards a single goal. Of the three roles, the role of the Scrum Master will be the focus of this article.We will talk about the qualities that make a successful Scrum master stand out from the crowd and discuss the major skill sets that employers seek from Scrum masters.Later, we will delve into how best to prepare for this role and how necessary it is for a Scrum master to possess technical knowledge related to the product or technology the team is working on. Finally, we will address how a Scrum Master can accelerate change and positively impact delivery in the team.  What is a Scrum Master?  Scrum Masters are facilitators of Scrum who act as servant leaders to drive the delivery in terms of process and product. As facilitators, scrum masters act as coaches to the rest of the team, “servant leaders” as the Scrum Guide puts it. Good scrum masters are committed to the scrum foundation and values, but remain flexible and open to opportunities for the team to improve their workflow. The Scrum Master is responsible for promoting and supporting Scrum as defined in the Scrum Guide. They do this by helping the team and the management understand Scrum theory, practices, rules, and values.  Roles of a Scrum Master  The scrum master is the role responsible for gluing everything together and ensuring that scrum is being done well. In practical terms, that means they help the product owner define value, the development team deliver the value, and the scrum team to get to get better. The scrum master is a servant leader which not only describes a supportive style of leadership but describes what they do on a day-to-day basis. The several ways that a Scrum master services the product owner, the Scrum Team and the organization are elaborated below:  The Scrum Master wears different hats to deliver results. The four main stances of a Scrum Master are explained below:  As a Facilitator – The Scrum Master is a facilitator who makes sure the team is following the scrum events by serving and empowering the team in achieving their objectives. The person must be ‘neutral’ without taking sides in any conversation or meeting, at the same time, back everyone to do their best in intellectual and in practice. On the lines of facilitation, Lyssa Adkins provides a very apt statement:   "A Scrum Master should facilitate by creating a "container" for the team to fill up with their ideas and innovations. The container, often a set of agenda questions or some other lightweight (and flexible) structure, gives the team just enough of a frame to stay on their purpose and promotes an environment for richer interaction, a place where fantastic ideas can be heard. The coach creates the container; the team creates the content.”  Lyssa Adkins  As a Coach – The Scrum Master helps the team to understand the framework and accordingly coaches them for being self-organized and cross-functional. This person inspires an outlook of continuous improvement and Back the team in problem-solving and conflict resolution.   As a Servant Leader – The term Servant Leader was originated by Robert K. Greenleaf, who described this term as “The servant-leader is servant first. It begins with the natural feeling that one wants to serve. Then conscious choice brings one to aspire to lead.”  “The servant-leader is servant first. It begins with the natural feeling that one wants to serve. Then conscious choice brings one to aspire to lead.”  Robert K. Greenleaf  This person ‘leads by example’ and puts the team/individuals' needs on priority. They make sure they are setting the foundation of trust, honesty, transparency, and openness. At the same time, they are the leader whom the team can look up to.   As a Change Agent – The scrum Master brings about the change in terms of process, practices, and ways of working. They act as a catalyst in the overall transformation to bring about the degree of change expected from an organization. They help the team follow the process along with helping the stakeholders understand the empirical process. They help the entire team to adopt processes and enhance the delivery.  [Tweetable snippet:   Scrum myth: The scrum master must run the daily scrum. In fact, the scrum master does not run anyof the events, just ensures they happen and that they are successful.]  Top Qualities of a Successful Scrum Master  As with other roles, there is a secret sauce that goes into making the Scrum Master successful. While every individual serving as a Scrum Master may bring along their own personalities and strengths to reinforce the role, there are a couple of must-have qualities which every individual donning the Scrum Master role must hone. Let’s take a quick look at these traits that can add a pinch of charm to the Scrum Master role.  Powerful Communicator – The Scrum Master needs to be very specific and clear on the communication they have with the team and with stakeholders. They must be aware of the right channels and when to use them. They should know how to influence teams for better results.  Inspires Ownership – A good Scrum Master helps the team to understand Agile principles and why the team can gain better results through the adoption of ownership. They help the team to take ownership of their tasks, their task board, process, and even small failures.  Read the Room – The Scrum Master should be able to understand and sense the temperature of the room. They should know when conflict is cropping up and how to deal with it smartly. This helps to build a culture of trust and transparency amongst the teams.  Impartial – The Scrum Master can become a star leader if they are neutral towards any situation or the individual. They focus on the problem rather on the individual. They know every individual is good and has the right intentions, it is just the situations that alter the way the team behaves. This not only helps in creating a rapport, but also gives one the satisfaction of doing the right thing.   Scrum Master Job Description and Responsibilities  With the increase in demand for Scrum Masters globally, it is important to understand the job description. Every industry is different and so are their ways of working. While each organization may have their own versions of the job description for a Scrum Master as per their need in a project, we will take a closer look into the typical job description that organizations use.   Below are some of the common points you will usually find in an open position for a Scrum Master:  Standups: Organize daily stand-up meetings, facilitate, and plan other project meetings as required including demos as suitable.  Sprint reviews: Empower team to become self-organized to consistently deliver on their sprint commitments.  Adoption of best practices - Ensure development teams enthusiastically apply core agile principles of collaboration, prioritization, accountability, and visibility.  Impediment removal - Responsible to address impediments that prevent successful development and testing of approved requirements.  Visualization of issues - Support team to detect barriers that prevent it from delivering features to the customers.  Agile master - Strong knowledge of Scrum philosophy, rules, practices, and other frameworks.  Understanding of the software development process - Familiarity with software development processes and measures to understand team requirements.  Process ownership: Harmonize scrum team with agile; collaborate with Leadership to ensure delivery teams practice Agile framework and software engineering best practices.  Stakeholder management -Work in partnership with Stakeholders, Product Managers, Business Analysts, and development managers to plan releases and manage a healthy product backlog  Metrics/reports - Endorse and present appropriate metrics to sustain continuous improvement to get the best out of each team. Report progress, team status, and issues across the board.  Transparency -Communicate development status to sponsors, participants, management, and teams. Shares weekly or bi-weekly reports to ensure everyone understands the current state.   Quality -Safeguard observance of quality standards and project deliverables. Understand principles to drive quality ethics and help in devising tools and practices for best end results.   How can I prepare for this role?  Donning the role of a Scrum Master is akin to heeding to an internal calling; the role requires a person to be patient, a good communicator, a good listener, and most of all emotionally intelligent. If you want to become a Scrum Master, make sure you understand the in-depth meaning of servant leadership. It is not just following the process and events that make up a Scrum Master, it is a huge role which requires leadership while serving the team. If this is your calling, then here are some steps you can take –   Start learning about Scrum and how effectively you can use its values and principles with your team  Start reading articles and blogs on best practices with success stories.  Prepare for the certification required to start your journey.  Make sure you have a mentor who can shape you well and can help you hone your skills  Continuously work on your communication and influencing skills.  Is it essential for a Scrum Master to possess technical knowledge?  Of late, we have started noticing many job postings where organizations specifically demand a Scrum Master who is technically sound and knows the in and out of the technology the team is working on. Traditionally, however, Scrum Master is a non-technical role where the focus is on improving the work culture, adopting Scrum/Agile and its best practices, and helping the teams to grow, become self-organized and high performing. While it is a good-to-have criterion, technical knowledge is not mandatory. But then again, it really depends on the organization and their need.  Get started with the Scrum Master role  If you want to help teams work effectively together and want to change the world with scrum and agile, then the scrum master role is for you. It is a very people-centric role with a heavy emphasis on coaching, teaching, and facilitation. The Scrum Master role can be a game-changer for project delivery. They help the team understand their true potential which most of the times teams themselves are not aware of, with the help of coaching, mentoring, and using engaging team activities that help in understanding the overall process and delivery.  The Scrum Master role is critical and needs to be handled with care as the stakes are high. This role has a high degree of accountability and responsibility towards the team, process, and organization which not only requires an open mindset but also a concern for the wellbeing of co-workers. If lived to its full potential, this role can build awesome high-performing teams that sustain hardships and efficiently draw learning out of every experience. Such teams are bound to succeed at every step, taking even failure as a step towards success. 
Rated 4.5/5 based on 20 customer reviews
29660
Scrum Master Job Descriptions and Responsibilities...

Scrum stands out as one of the most dominant A... Read More

Useful links