Category

Courses

Search

Trending blog posts

User Stories and User Stories Examples

In this article, you will learn about User Stories, 3 C’s of a user story, who writes it, how to write it, how to INVEST in user stories and different types of user stories with examples  What is a User Story? User Story is a tool in which requirements are captured in an easy to understand plain language, and is written from the perspective of an end user. “In software development and product management, a user story is an informal, natural language description of one or more features of a software system. User stories are often written from the perspective of an end user or user of a system” In Agile software development, user stories are used to express the requirements from an end user perspective.  The format of the user story is: As a <user>  I want to <perform an action>  So that <I expect….> <User> - is the end user or the role of the user in the application software – “As a net banking customer” <perform an action> - the action the user is performing on the application software – “I want to add beneficiary in my account” <I expect..> - outcome, desired value, the user expects out of the action performed – “so that I can transfer money to the added beneficiary”The larger sized stories are called as “Epics” which are then decomposed to “Features” and then further decomposed to a “User Story”.  Epic example: As a Bank, I want to provide net banking to customers, so that they can perform various transactions. The above Epic can then be decomposed into multiple features: few examples: As a Bank, I want to provide funds transfer feature to customer, so that they can transfer funds from one account to another account As a Bank, I want to provide account summary for all the customer’s type of accounts. As a Bank, I want to provide credit card details to customers. Now each feature can be decomposed further into multiple user stories. User stories, based on the estimate size, are taken for implementation in an iteration. User stories should be granular enough that they can be completed within an iteration and cannot be continued in the following iteration. If a story cannot be completed within an iteration, the same should be split logically. User stories are prioritized by the product owner based on business priority and are available at the top of the product backlog. The dev team pulls the stories into an iteration backlog and implements them. The Definition of Done(DOD) for user stories are decided by the team which includes acceptance criteria, processes that need to be followed like unit testing, regression testing, code review etc. The story is said to be “done” only when it meets the preset Definition of Done. Who writes user stories? So, whose responsibility is to write user stories in an agile team?  Generally, the notion is that only the Product Owners should write user stories as they are the ones who elicit requirements from the stakeholders. However, in practice, any member of an Agile team may write user stories, though the overall responsibility is that of a Product Owner. The product owner should go through the stories and prioritize them in the product backlog. Over the course of an agile project, every team member is encouraged and expected to write user stories. When are user stories written? Are user stories written at the beginning of the project in a traditional way?  User stories are written throughout the lifecycle of the project. At the start of the project, user stories are written in Sprint '0', also called as pre-sprint. Initially the product owner elicits the requirements from the stakeholder and they are stored as EPICS, Features and User Stories in the product backlog. The requirements in agile software development are progressively elaborated and hence the need for writing user stories will arise throughout the project. These are written mainly during the backlog grooming session where the product owner decomposes epics/features into granular stories. Dev team writes stories along with the product owner during this session and also gets  involved in the 3 C’s (the next section describes this). confirmation in the 3C’s of user stories “Card”, “Conversation” and “Confirmation” is a model that captures the components of a user story.  This is popularly known as the 3Cs model that helps in planning and estimating the user stories by the Agile team. Card – denotes a Post It note or physical card, typically 3”x5” size, where the important information of a user story is captured. The card should contain enough information (not too less or too much) that the team is able to understand in order to plan & estimate on the story. “Conversation” – this is the conversation that happens between the product owner and the dev team to discuss on the story and get into the details. This may also be a conversation with the users of the system. This conversation also brings out the creativity of the dev team and uncovers any unstated needs of the users. “Confirmation” – this brings out the acceptance criteria for a story based on the above conversation.  This criterion will be used to evaluate the story by the stakeholders when the user story is implemented by the dev team.  The 3 C’s of the user story generally unfold during the backlog grooming session when the dev team and the product owner discuss the stories that needs to be groomed. The user stories are written during this time as well on the card by the dev team and product owner. Just enough information is captured in the story that enables the team to discuss and get into the details, uncovering any hidden or explicit information in the process. The team then negotiates with the product owner and arrives at the acceptance criteria for the user story.  Next, the dev team estimates the user story with the available information. The conversation continues between the dev team and product owner until a consensus is reached with respect to the details and acceptance criteria and until the team can size the same. This round of conversation may happen again during the iteration/sprint planning session. The dev team then implements the story in an iteration which is reviewed by the product owner or stakeholders at the end of the iteration. They will then accept the story based on the acceptance criteria defined for the story. Why create user stories? What are the benefits that a team will get by documenting the need of the stakeholders in the form of user stories? It enables the team to understand the requirements from a user perspective. The focus is on the user to provide value to them; the user story clearly describes the expected outcome of every action performed. This manner of capturing requirements provides opportunities for the team to collaborate more with the product owner and business users. By having conversations (in 3 Cs), the team is able to uncover the hidden requirements and also come up with creative solutions. Provides a shared understanding of the requirements to the team so that everyone is aware of the outcome/goal of the story and is on the same page. User stories help the team to achieve smaller product increments. User stories are more understandable by all stakeholders (technical/non-technical/business/operations). User stories help the team to implement features in smaller iterations ranging from one week to one-month durations. User stories enable the team for progressive elaboration, where they can defer the story until more clarity is obtained. User stories help create transparency of the priorities defined by the product owner and the customer. User stories help the developers, product owner and business owners to reach a mutual consensus as they discuss the details and agree on the acceptance criteria. This helps prioritize the product features by the stakeholders and also helps to take the right decisions at the right time. INVEST in User StoriesThis is an acronym for a set of attributes or criteria that helps us to assess the quality of the user story. If any of the attributes falls short in a story, it means that the team may want to consider rewriting the user story. Independent – User stories should be independent of other stories. There should be no overlap between them. They can however follow one after the other in a sequence, in a way that makes it easy to schedule and implement them.  This is one of the challenges that the team faces especially when they have just started adapting agile ways of working. They may have a story which is dependent on something else which may be done by another team. The teams may hope that they can run the two stories in parallel and by the time the first team is done, the dependent team will also complete their part of the story.  This is not the right way of running user stories, as it can result in a lot of confusion and blame. The advantage of having independent stories is that there is no blame game across teams. It also allows to consider the dependencies and come up with innovative ways of removing them to become independent. Negotiable – The story should not be written in so much detail that it becomes a requirement document. If it is in too much detail, it does not give an opportunity for the dev team to have any conversation with the product owner or the business. The story should be written with just enough detail so that it paves the way to open discussions with the product owner or business, and helps to elicit details or come up with creative solutions. By negotiating on the story with the relevant stakeholders, teams can come to a common understanding. Valuable – The story should be valuable to the customer. It should clearly state why we are doing this? How is it going to produce value to the customer? What value will the customer realize by implementing this story?  The only reason why user stories should be part of the product backlog is that they add value to the customer, right? Estimable – The user stories should have sufficient detail for the dev team to understand and estimate them. The conversation in 3 C’s helps the team to uncover the details with the product owner and stakeholders, so that they can size the story. If the story is too big and not sizeable, then the story should be refined or decomposed further. Whatever information the team may require should be available in the story for them to estimate it. In case there is a part of the story where the team has to do research, then a “spike” story may be created while the rest of the story can be estimated and taken for implementation. Small – Good user stories should be small. This does not refer to the size or number of words written in a story. A small story is of the right length so that the implementation team can complete the story within an iteration. It should be small enough that the story is “fully delivered” during an iteration.  A small user story helps the team to develop and test quickly and easily.  Testable – A good user story should be testable in order to be “Done”. This is supported by the “Confirmation” in 3 C’s where the team comes up with acceptance criteria for every story after the detailed conversation with the stakeholders.  The customer should be clear about what he should test during the review. If he is not clear, then the story is not good enough to be implemented. The team works together in a collaborative way to INVEST in good stories. The team learns to write good user stories as they work together and also proactively think about the values and criteria that are laid out in INVEST. Types of User Stories We can classify user stories into functional and technical types: Functional – Normally, a user story is written based on the functional aspects of the application software, while focusing on the user and the value of the functionality provided to the user.  Functional stories concentrate on the product features which the customer will be testing at the end of an iteration based on the acceptance criteria defined for the story. Technical – Technical stories are written to be able to support the functional stories. Technical stories can be classified as Infrastructure stories – any infrastructure addition/modification that may be required to support the functional story Refactoring – this type of story is written to maintain the code and address technical debts. This can be used for designing and automation needs as well Spikes – stories that require research on architecture and design which may in turn help achieve the functional need of the customer. Examples of user stories Let us see some examples of user stories (Epics, Features and User Story) in this section. IDEPICSE1As a Sales Professional, I want to generate reports so that I can take a decision on the marketing strategy for the upcoming quarterE2As a Banking Customer, I want to access net banking, so that I can access my account and make transactionsE3As an Administrator of the software, I want to access master records so that I can make changes to customer dataIDFeaturesE2F1As a Banking Customer, I want to access Savings account so that I can view/make transactionsE2F2As a Banking Customer, I want to access Credit Card page, so that I can view and make transactionsE2F3As a Banking Customer, I want to access Loans page so that I can view my loansE2F4As a Banking Customer, I want to transfer funds, so that I can move my funds to different accounts within my bank and other banksIDUser StoriesE2F1U1As a Banking Customer, I want to access/view summary of my savings account, so that I know my balance and other detailsE2F2U1As a Banking Customer, I want to Login to Net banking so that I can view credit card detailsE2F4U1As a Banking Customer, I want to transfer funds within my own accounts so that I can move some balance across my accountsE2F4U2As a Banking Customer, I want to transfer funds from my account to another account in another bank, so that  I can send money to my family and friends who have accounts in other banksE2F4U3As a Banking Customer, I want to add beneficiary to my account, so that I can transfer funds to the beneficiaryTechnical StoriesE2TU1As a Net Banking Administrator, I want to have the customer’s data backed up so that I can restore it any time in case of issues  E2TU2  As a Net Banking application, I want to shake hands with another bank using a specific formatted XML so that funds can be transferred based on the customers’ needs  Conclusion Transformation of documentation on user requirements in a Functional Requirements Document (FRD) or Software Requirement Specification (SRS) in a traditional project management, towards User Stories in Agile project management, is a massive step. It helps  shift the mindset of how teams can understand and collaborate with the customer in a better way, by shifting their focus of implementation towards value that the customer may realize from the story. This shift has worked very well in terms of meeting the requirements and expectations of the customer. 
User Stories and User Stories Examples
Krishnakumar

User Stories and User Stories Examples

In this article, you will learn about User Stories, 3 C’s of a user story, who writes it, how to write it, how to INVEST in user stories and different types of user stories with examples  What is a User Story? User Story is a tool in which requirements are captured in an easy to understand plain language, and is written from the perspective of an end user. “In software development and product management, a user story is an informal, natural language description of one or more features of a software system. User stories are often written from the perspective of an end user or user of a system” In Agile software development, user stories are used to express the requirements from an end user perspective.  The format of the user story is: As a   I want to   So that   - is the end user or the role of the user in the application software – “As a net banking customer”  - the action the user is performing on the application software – “I want to add beneficiary in my account”  - outcome, desired value, the user expects out of the action performed – “so that I can transfer money to the added beneficiary”The larger sized stories are called as “Epics” which are then decomposed to “Features” and then further decomposed to a “User Story”.  Epic example: As a Bank, I want to provide net banking to customers, so that they can perform various transactions. The above Epic can then be decomposed into multiple features: few examples: As a Bank, I want to provide funds transfer feature to customer, so that they can transfer funds from one account to another account As a Bank, I want to provide account summary for all the customer’s type of accounts. As a Bank, I want to provide credit card details to customers. Now each feature can be decomposed further into multiple user stories. User stories, based on the estimate size, are taken for implementation in an iteration. User stories should be granular enough that they can be completed within an iteration and cannot be continued in the following iteration. If a story cannot be completed within an iteration, the same should be split logically. User stories are prioritized by the product owner based on business priority and are available at the top of the product backlog. The dev team pulls the stories into an iteration backlog and implements them. The Definition of Done(DOD) for user stories are decided by the team which includes acceptance criteria, processes that need to be followed like unit testing, regression testing, code review etc. The story is said to be “done” only when it meets the preset Definition of Done. Who writes user stories? So, whose responsibility is to write user stories in an agile team?  Generally, the notion is that only the Product Owners should write user stories as they are the ones who elicit requirements from the stakeholders. However, in practice, any member of an Agile team may write user stories, though the overall responsibility is that of a Product Owner. The product owner should go through the stories and prioritize them in the product backlog. Over the course of an agile project, every team member is encouraged and expected to write user stories. When are user stories written? Are user stories written at the beginning of the project in a traditional way?  User stories are written throughout the lifecycle of the project. At the start of the project, user stories are written in Sprint '0', also called as pre-sprint. Initially the product owner elicits the requirements from the stakeholder and they are stored as EPICS, Features and User Stories in the product backlog. The requirements in agile software development are progressively elaborated and hence the need for writing user stories will arise throughout the project. These are written mainly during the backlog grooming session where the product owner decomposes epics/features into granular stories. Dev team writes stories along with the product owner during this session and also gets  involved in the 3 C’s (the next section describes this). confirmation in the 3C’s of user stories “Card”, “Conversation” and “Confirmation” is a model that captures the components of a user story.  This is popularly known as the 3Cs model that helps in planning and estimating the user stories by the Agile team. Card – denotes a Post It note or physical card, typically 3”x5” size, where the important information of a user story is captured. The card should contain enough information (not too less or too much) that the team is able to understand in order to plan & estimate on the story. “Conversation” – this is the conversation that happens between the product owner and the dev team to discuss on the story and get into the details. This may also be a conversation with the users of the system. This conversation also brings out the creativity of the dev team and uncovers any unstated needs of the users. “Confirmation” – this brings out the acceptance criteria for a story based on the above conversation.  This criterion will be used to evaluate the story by the stakeholders when the user story is implemented by the dev team.  The 3 C’s of the user story generally unfold during the backlog grooming session when the dev team and the product owner discuss the stories that needs to be groomed. The user stories are written during this time as well on the card by the dev team and product owner. Just enough information is captured in the story that enables the team to discuss and get into the details, uncovering any hidden or explicit information in the process. The team then negotiates with the product owner and arrives at the acceptance criteria for the user story.  Next, the dev team estimates the user story with the available information. The conversation continues between the dev team and product owner until a consensus is reached with respect to the details and acceptance criteria and until the team can size the same. This round of conversation may happen again during the iteration/sprint planning session. The dev team then implements the story in an iteration which is reviewed by the product owner or stakeholders at the end of the iteration. They will then accept the story based on the acceptance criteria defined for the story. Why create user stories? What are the benefits that a team will get by documenting the need of the stakeholders in the form of user stories? It enables the team to understand the requirements from a user perspective. The focus is on the user to provide value to them; the user story clearly describes the expected outcome of every action performed. This manner of capturing requirements provides opportunities for the team to collaborate more with the product owner and business users. By having conversations (in 3 Cs), the team is able to uncover the hidden requirements and also come up with creative solutions. Provides a shared understanding of the requirements to the team so that everyone is aware of the outcome/goal of the story and is on the same page. User stories help the team to achieve smaller product increments. User stories are more understandable by all stakeholders (technical/non-technical/business/operations). User stories help the team to implement features in smaller iterations ranging from one week to one-month durations. User stories enable the team for progressive elaboration, where they can defer the story until more clarity is obtained. User stories help create transparency of the priorities defined by the product owner and the customer. User stories help the developers, product owner and business owners to reach a mutual consensus as they discuss the details and agree on the acceptance criteria. This helps prioritize the product features by the stakeholders and also helps to take the right decisions at the right time. INVEST in User StoriesThis is an acronym for a set of attributes or criteria that helps us to assess the quality of the user story. If any of the attributes falls short in a story, it means that the team may want to consider rewriting the user story. Independent – User stories should be independent of other stories. There should be no overlap between them. They can however follow one after the other in a sequence, in a way that makes it easy to schedule and implement them.  This is one of the challenges that the team faces especially when they have just started adapting agile ways of working. They may have a story which is dependent on something else which may be done by another team. The teams may hope that they can run the two stories in parallel and by the time the first team is done, the dependent team will also complete their part of the story.  This is not the right way of running user stories, as it can result in a lot of confusion and blame. The advantage of having independent stories is that there is no blame game across teams. It also allows to consider the dependencies and come up with innovative ways of removing them to become independent. Negotiable – The story should not be written in so much detail that it becomes a requirement document. If it is in too much detail, it does not give an opportunity for the dev team to have any conversation with the product owner or the business. The story should be written with just enough detail so that it paves the way to open discussions with the product owner or business, and helps to elicit details or come up with creative solutions. By negotiating on the story with the relevant stakeholders, teams can come to a common understanding. Valuable – The story should be valuable to the customer. It should clearly state why we are doing this? How is it going to produce value to the customer? What value will the customer realize by implementing this story?  The only reason why user stories should be part of the product backlog is that they add value to the customer, right? Estimable – The user stories should have sufficient detail for the dev team to understand and estimate them. The conversation in 3 C’s helps the team to uncover the details with the product owner and stakeholders, so that they can size the story. If the story is too big and not sizeable, then the story should be refined or decomposed further. Whatever information the team may require should be available in the story for them to estimate it. In case there is a part of the story where the team has to do research, then a “spike” story may be created while the rest of the story can be estimated and taken for implementation. Small – Good user stories should be small. This does not refer to the size or number of words written in a story. A small story is of the right length so that the implementation team can complete the story within an iteration. It should be small enough that the story is “fully delivered” during an iteration.  A small user story helps the team to develop and test quickly and easily.  Testable – A good user story should be testable in order to be “Done”. This is supported by the “Confirmation” in 3 C’s where the team comes up with acceptance criteria for every story after the detailed conversation with the stakeholders.  The customer should be clear about what he should test during the review. If he is not clear, then the story is not good enough to be implemented. The team works together in a collaborative way to INVEST in good stories. The team learns to write good user stories as they work together and also proactively think about the values and criteria that are laid out in INVEST. Types of User Stories We can classify user stories into functional and technical types: Functional – Normally, a user story is written based on the functional aspects of the application software, while focusing on the user and the value of the functionality provided to the user.  Functional stories concentrate on the product features which the customer will be testing at the end of an iteration based on the acceptance criteria defined for the story. Technical – Technical stories are written to be able to support the functional stories. Technical stories can be classified as Infrastructure stories – any infrastructure addition/modification that may be required to support the functional story Refactoring – this type of story is written to maintain the code and address technical debts. This can be used for designing and automation needs as well Spikes – stories that require research on architecture and design which may in turn help achieve the functional need of the customer. Examples of user stories Let us see some examples of user stories (Epics, Features and User Story) in this section. IDEPICSE1As a Sales Professional, I want to generate reports so that I can take a decision on the marketing strategy for the upcoming quarterE2As a Banking Customer, I want to access net banking, so that I can access my account and make transactionsE3As an Administrator of the software, I want to access master records so that I can make changes to customer dataIDFeaturesE2F1As a Banking Customer, I want to access Savings account so that I can view/make transactionsE2F2As a Banking Customer, I want to access Credit Card page, so that I can view and make transactionsE2F3As a Banking Customer, I want to access Loans page so that I can view my loansE2F4As a Banking Customer, I want to transfer funds, so that I can move my funds to different accounts within my bank and other banksIDUser StoriesE2F1U1As a Banking Customer, I want to access/view summary of my savings account, so that I know my balance and other detailsE2F2U1As a Banking Customer, I want to Login to Net banking so that I can view credit card detailsE2F4U1As a Banking Customer, I want to transfer funds within my own accounts so that I can move some balance across my accountsE2F4U2As a Banking Customer, I want to transfer funds from my account to another account in another bank, so that  I can send money to my family and friends who have accounts in other banksE2F4U3As a Banking Customer, I want to add beneficiary to my account, so that I can transfer funds to the beneficiaryTechnical StoriesE2TU1As a Net Banking Administrator, I want to have the customer’s data backed up so that I can restore it any time in case of issues  E2TU2  As a Net Banking application, I want to shake hands with another bank using a specific formatted XML so that funds can be transferred based on the customers’ needs  Conclusion Transformation of documentation on user requirements in a Functional Requirements Document (FRD) or Software Requirement Specification (SRS) in a traditional project management, towards User Stories in Agile project management, is a massive step. It helps  shift the mindset of how teams can understand and collaborate with the customer in a better way, by shifting their focus of implementation towards value that the customer may realize from the story. This shift has worked very well in terms of meeting the requirements and expectations of the customer. 
User Stories and User Stories Examples
Blogs
9429
User Stories and User Stories Examples

In this article, you will learn about User Stories... Read More

Waterfall Vs Agile – Must Know Differences

In this article, my focus is to the bring out the differences between Waterfall and Agile methodologies based on my experience as a PMP® and Agile Coach.  What will you learn in this article? In this article, you will learn the definition of Waterfall and Agile, key differences between the two, advantages and limitations of each, how to make the right choice for your project and an example on Waterfall and Agile methods. What is Waterfall Methodology?  “The first formal description of the waterfall model is often cited as a 1970 article by Winston W. Royce, although Royce did not use the term waterfall in that article….The earliest use of the term "waterfall" may have been in a 1976 paper by Bell and Thayer” This methodology describes a linear and sequential approach to Software Development. It is termed “Waterfall” as the life cycle phases in the Software Development cascade from one phase to another systematically from top to bottom. After the completion of every phase, the subsequent phase is expected to start and there is a stage-gate or kill-point review at the end of each phase. Progress of the project is evaluated during this stage-gate review and the decision is made to continue to the next phase or cancel the project. For example, the entire requirements for the project are elicited by the project team from the stakeholders and documented. The team can proceed to the next phase –Design- only after the evaluation of the requirements during the stage-gate review is completed, and a “Go” decision is made. This is also known as Traditional or Predictive approach in project management, as it applies a predictive planning strategy which uses baselines and milestones to control the project.  What is Agile Methodology? “The appearance of Agile methods has been the most noticeable change to software process thinking in the last fifteen years [16], but in fact many of the “Agile ideas” have been around since 70’s or even before. Many studies and reviews have been conducted about Agile methods which ascribe their emergence as a reaction against traditional methods” This approach of software development is also known as Adaptive approach. Agile Methodology promotes an iterative & incremental approach throughout the entire software development life cycle of the project. This focuses on the values and principles defined in the Agile Manifesto which states Agile Manifesto: Individuals and Interactions over processes and tools Working Software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan Principles: Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. Business people and developers must work together daily throughout the project. Build projects around motivated individuals. Give them the environment and support they need and trust them to get the job done. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. Working software is the primary measure of progress. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace, indefinitely. Continuous attention to technical excellence and good design enhances agility. Simplicity–the art of maximizing the amount of work not done–is essential. The best architectures, requirements, and designs emerge from self-organizing teams. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly. Key differences between Waterfall and Agile MethodologyRequirements: In traditional approach, an extensive business analysis is performed (typically by the business analyst) in order to meet the requirements of the product, service or result. Requirements are fully documented and signed off by the key stakeholders. The business analyst walks through the requirements to the project team which then performs the design, development and testing of those requirements. Since requirements are elicited at the beginning of the project and subsequently baselined, it is possible that requirements may decay over a period as the business dynamics keep changing in today’s world. In Adaptive approach, the requirements are progressively elaborated and stored in the requirements backlog or product backlog. They are stored in the form of Epics/Features/User Stories in the product backlog.  The entire agile team collaborates on grooming the requirements later.   Responding to Changes: Waterfall methodology tries to control the amount of change within a project. It is very rigid to any change in the project and has to go through a process of change requests. Change management plan is well defined to handle any change in a systematic manner to avoid scope creep or gold plating (doing something extra for the customer without them actually asking for it). Welcome change is a powerful tool in adaptive approach. The agile approach to planning, executing, prioritizing, grooming etc allows the agile team to respond to change quickly. Changes are considered as opportunities to provide value to the customer. Please note “responding” to changes does not mean “accepting” all the changes. It is rather “welcome changes” as the agile team collaborates with the customer more from the value perspective.  Project Team: There is no specific team size limit in the traditional approach. It can go from a few team members to hundreds in a huge project. This limits the collaboration between the individuals involved in the project, especially in a big-sized team. Team members may be allocated from different functional units and may not be seated together. In Agile methodology, team size is limited to achieve high collaboration through co-location (team sitting together in the same workspace). Each agile team comprises of a cross-functional team who can produce a working software increment in every iteration. Development Life Cycle: In Waterfall methodology, the software development life cycle goes through a series of phases like requirements, design, coding, testing and UAT, sequentially. The entire product or working software is available at the end of the project phase. In Agile methodology, the development happens in iterations/sprints, and the duration of the iterations ranges from two weeks to a month. The phases of analysis, design and development happens within an iteration and the team is able to produce a working software increment in every iteration. Feedback cycle: In Waterfall methodology, the feedback of the project is received at the end of the project when the customer conducts the validate scope process (UAT). In Agile methodology, feedback of the increment is received by the team at the end of every iteration. Multiple feedback loops provide opportunities for the team to learn quickly. Testing: In waterfall methodology, testing cycle or phase starts after the development phase is completed. Test plans are finalized at the beginning of the project and test cases are written for the product of the project while the development is in progress. Development and test teams are looked at separately within a project team. In Agile methodology, every iteration planning includes planning for test and test cases are written for those prioritized features or stories for every iteration. Testers and coders work in an integrated manner to deliver the product increment. Focus: In waterfall methodology, the focus is more on producing the project deliverable as defined and baselined. In Agile methodology, the focus is more on collaborating with the customer and welcoming changes that provide value to the customer. Documentation: In waterfall methodology, due importance is given to formalized documentation which helps in monitoring and controlling of the project for the project manager. In Agile methodology, minimal documentation is prescribed as working software is preferred over comprehensive documentation (as per Agile Manifesto). Roles: In waterfall methodology, there can be many roles defined like Project Manager, team lead, developer, tester, business analyst, design architect, quality analyst etc., In Agile methodology, roles are very limited. Especially in Scrum framework, there are only 3 roles. Scrum Master, Product Owner and Development Team (cross functional team). Project Management: In Waterfall methodology, project manager is responsible for managing the project and is accountable for the entire project. Project manager manages the project team by assigning work to the team members and getting the task done. In other words, project manager “pushes” the work to the team. In Agile methodology, the team manages the project themselves as they are a self-organizing team. The team “pulls” the work from the product backlog into the iteration backlog. Team Empowerment: In waterfall methodology, the project manager is directly answerable for the outcome of the project and team members are not empowered to take decisions. In Agile methodology, the agile team is empowered to take decisions and hence they are collectively accountable for the outcome of the project. Project Metrics: In waterfall methodology, the project team measures the project progress using techniques like Earned Value Management and Schedule compression to compress the schedule in case of any deviations. In Agile methodology, the metrics are derived in terms of velocity (how many story points the team produced during an increment cycle) and other metrics like sprint burndown/burnup charts to monitor daily progress within an iteration. Advantages and Limitations of Waterfall MethodologyAdvantages:Ability to apply due diligence in planning for well-defined requirements and scope Dependencies are managed effectively as the entire requirements are known well in advance Well defined processes pave the way for quality deliverables Phase-gate reviews allow stakeholders to eliminate any ad-hoc changes and unplanned additions to the project Works well for small projects for a well-defined requirement that is very well understood, and is not likely to change over the duration of the project Avoids scope creep with systematic implementation of change management process Simple and easy to understand Scope, time and cost baseline helps the management to monitor and control the project accordingly Limitations:Requirements are expected to be defined well prior to development which delays the project Less flexibility in changes makes it difficult to manage Feedback is received from the customer at the end of the project and hence any negative feedback or defects proves costly for the team to fix  Does not accommodate any changes due to market dynamics and its rigid approach to changes Cost of change is more as the defect is identified by the customer at the end of the project Ineffective team collaboration as the team works in silos (dev, testing etc) Integration is considered at the end and that prevents identification of any technical or business bottleneck Advantages and limitations of Agile MethodologyAdvantagesFocusses on business value as developers and business work together Stakeholders are engaged effectively in every iteration Motivated and self-organizing teams that manage themselves Predictable and ensures less variations in the project Harnesses change and is more customer centric Working software is the measure of progress. Feedback is received from the key stakeholder during every iteration and the cost of change is very less Teams retrospect every iteration to look at improvement areas and finetune themselves Provides transparency through the process Focuses on Minimum Viable Product to release to the customer Due attention is paid to specific customer needs and changes are accommodated even late in development Limitations Not suitable for all types of projects May not work well in a large traditional organization due to its flexible and less formal processes Minimal depth in requirement analysis and frequent planning may derail the end project goals Self-organizing and empowering teams solely depends on team’s maturity level at handling decisions and may backfire Working software over comprehensive documentation is misunderstood and hence teams may not focus even on necessary documentation that is required Waterfall vs Agile Methodology – Which is right for your project? A typical question that is raised before the software development starts is “which approach should we follow, Waterfall or Agile?”   The following table can be used to determine the approach (please note all the factors do not carry equal weightage)     Waterfall (works)Agile (works)Well defined scope and changes are very limitedScope/FeaturesWhen scope is not known in advance or changes are expected as the project moves onWhen uncertainty is low and low-level riskRiskWhen uncertainty is high and high-level riskWhen market is stableMarket dependencyWhen market dynamics change/evolve frequentlyWhen customer involvement is required only at certain milestonesCustomer FeedbackWhen customer is available and requires involvement throughout the projectWhen the focus is on planning, monitoring and control and predictabilityFocusWhen the focus is on innovationWhen conforming to requirements as agreed upon in the contractProduct FeaturesWhen minimum viable product (which gives more value to the customer) is implemented first and we can implement the low valued features laterWhen a large sized team with minimal collaboration or handoff is requiredTeamWhen small team with high collaboration is requiredWhen the budget is fixedFundingWhen the budget is not a constraintWhen it is less important and not urgentTime to MarketWhen it is critical, important, and urgent to meet the desired outcomeExamples of Agile vs Waterfall: How is the software developed?  Waterfall Methodology: (example) Scope: To provide an employee timesheet software having the following features: Ability to login Ability for the employees to describe the task and enter the number of hours spent Ability to submit for approval to the manager Manager Ability to login Ability to add a resource to a project Ability to link project to a resource Ability to assign task to a resource Ability to approve/reject the timesheet Administrator Ability to login Ability to add/modify/delete users  Ability to add/modify/delete projects Reports Report on individual user timesheet data for a specified period Report on project timesheet data for a specified period Report on approved/rejected timesheets for a project for a specified period Let us assume the above is the scope and timeline for completion is given as 6 months. Requirements Phase: Detailed requirements on individual features are discussed and elicited from the stakeholders until they are well understood and documented. The requirements document is then signed off by the customer. Scope is identified and baselined during this phase. Project manager comes out with the detailed plan for the entire project and assigns team members accordingly to perform the task. The scope, schedule and cost are baselined considering all the other project constraints like resources, quality, risks, stakeholders, communication etc. Design and Development Phase: Development team works on design and coding all the requirements stated above and delivers to the testing team. Testing phase: Testing team validates the deliverables to see whether they conform to the requirements. They raise defects and the development team works on them. Testing team signs off on the deliverables once they work as per the requirements. UAT Phase: Customer validates the deliverables and signs off. Raises defects in case there are issues or requirements are not meeting the expectations Agile Methodology: (example) Scope: To provide the following features for an ATM Cash withdrawal Check balance Change ATM Pin Print statements Deposit Cash Deposit Cheque Product owner elicits high level requirements from the stakeholders and documents them in the form of features/user stories in the product backlog. Product Owner then prioritizes the features based on value that can be realized by the customer. Minimum viable product is finalized. 80/20 rule may be applied to find which 20% of the features give 80% value to the customer. In this case, Cash withdrawal and Check balance features are selected as the first increment to be implemented. Agile dev team along with the Product Owner sizes the features and stories and comes up with the release planning for the MVP identified. Product owner grooms and prioritizes the user stories in the product backlog. Agile team pulls the work in the iteration backlog and starts defining goals for every iteration until the features are completed. Meanwhile Product Owner continues to progressively elaborate the requirements for other features. Key business stakeholders, along with the Product Owner review the product increment created by the agile team and provide feedback. The team retrospect after each iteration with respect to people, process and product and finetunes accordingly. This iteration cycle goes on until the first implementation is complete and then the agile team takes up the next available set of features. Summary: As we have seen, Waterfall and Agile methodologies have their own set of advantages and limitations. While waterfall approach is more methodical and predictive, agile approach is more adaptive and dynamic in nature. Depending on the project circumstances and using the table provided under Waterfall vs Agile Methodology, the project team can decide which works better for them. 
Waterfall Vs Agile – Must Know Differences
Blogs
8566
Waterfall Vs Agile – Must Know Differences

In this article, my focus is to the bring out the ... Read More

Who Should Get CSPO® Certified?

In this article you would learn who is a Product Owner, and what are their roles and responsibilities while playing the role of a PO on a Scrum project. You would also learn about the CSPO® certification and its prerequisites, who all can attend the CSPO certification training and why should a PO get CSPO certified.  Who is a Product Owner?A product owner in Scrum is one of the three core roles and responsible for maximizing the value of the products and the work of the Scrum development team. This is a one-person role and is a bridge between the end-user and the development team. On the project, a PO plays different roles such as business strategist, product manager, product designer, market analyst, customer liaising and rarely Scrum Master. He or she has to be well versed with Agile/Scrum methodology.  What are the PO’s roles and responsibilities on a Scrum project? 1. Developing and maintaining a Vision and a product roadmapThe Scrum product owner is the point of contact on the product development team and uses a high-level perspective to define goals and creates a vision for the project. The PO is responsible for communicating with all stakeholders including customers, end-users and the development team to make sure that the goals are clear, and the vision is aligned with business objectives. This ensures that the team maintains a cohesive vision.The PO is also responsible for creating a product roadmap for the Scrum project. This product roadmap is a high-level, strategic visual summary that outlines the vision and direction for the product offering over time and acts as a strategic guide for stakeholders to reference and is also used as an execution plan.2. Ordering and managing the product backlogThe development team’s to-do list and one of the most important responsibilities for a Scrum Product Owner is managing the product backlog throughout the project.  Based on the overall strategy and business objectives the product owners create the list of backlog items and prioritize them. They will also need to map out project dependencies with the required sequence of development. The product backlog is a live document which is continually updated based on evolving project needs throughout development. Because it gets updated frequently, the product owner must make it accessible and available to all stakeholders, specifically the development team, to ensure optimized performance and project outcomes. 3. Overseeing development stagesWith the vision, product roadmap and product priorities set, the product owner should spend a significant amount of time overseeing the actual development of the product. They are a key contributor throughout each Sprint event including Sprint Planning, Backlog refinement, Sprint Review and Sprint Retrospective. During the planning stages, the product owner works with end-users to identify high-value items from the Product Backlog so that these items can be considered for the next Sprint or Iteration. At the end of every Sprint they will meet with the team to refine the process, identify areas for improvement and plan for the next sprint. 4. Anticipating and Prioritizing client needsThe Scrum Product Owner will be an expert at judging and anticipating the client’s needs to effectively manage the project and deliver a high-value product which can be used by everyone in the organization.5. Acting as primary liaisonThe product owner acts a link and is the primary communicator between the end-users and the development teams. They must be expert communicators, ensuring there’s buy-in from end-users on all major decisions strategically with clear instructions on deliverables for the developers.  6. Evaluating product progress at each iterationThe product owner is held accountable for each stage of the development process and the final product. They also take a prominent role in inspecting and evaluating product progress through each Sprint. The product owner is the one who makes the judgment call on the team's performance and decides if the team need to go back to the drawing board or they can move on to the next Sprint or next steps. A Product Owner is also responsible for defining high-level stories and should possess good decision-making and interpersonal skills while working on a Scrum project. What is a CSPO® certification?  CSPO stands for Certified Scrum Product Owner. It is an industry recognized certification for Product Owners who are already in the role of a Product Owner, or novices who would like to understand the insights of a Product Owner role.  After attending the training, each attendee would have the necessary knowledge to play the role of a PO on any Scrum project.  What are the pre-requisites to become a CSPO®? There are no specific prerequisites to attend a CSPO certification training course.Who can attend the CSPO® training? CSPO training can be attended by anybody who is knowledgeable and confident about the product under consideration, who is very good in communication, who is a good listener, who is focused on product development and who can quickly resolve issues and take decisions. Before selecting a person to attend the CSPO training and later play the role of a Product Owner it is always advisable to estimate the time and effort required for the Product Owner role. The estimates will come handy when the person who wishes to play the role is made aware of the period of time for which they are required to be available for the Scrum project. Suggested target audience could be – Business Analyst: Business Analysts are better suited to play the role of a Product Owner as they have the required knowledge on how to handle the business requirements and supplement it with business analysis. They play a critical role in decision-making during business analysis. Project Manager or Manager:  Project Manager is another role that is available to a Product Owner. Project Managers are involved in project planning and executing of a project i.e. throughout the lifecycle of a project right from ideation to closure. Hence, they would be more effective on a Scrum project to play the role of Product Owner.  In many organizations the Business Analyst also plays the role of Project Manager. It is for this reason that many organizations prefer Project Managers to play the role of a Product Owner. If these Project Managers have a Certified ScrumMaster certification then it would add value. Product Manager: Product Managers make very good Product Owners, as they have all the necessary knowledge about the product requirements based on strategic requirements and current market trends. If the Product Manager has Business Analysis experience, then this can add tremendous value to the Scrum project if he or she is appointed to play the role of a Product Owner. Functional Managers: Many organizations are structured by Functions and the Functional Managers report to the CEO. Functional Managers from any function would also be ideal to play the role of a Product Owner as they already have the necessary knowledge about the product, strategy and market trends. They understand the business requirements and they have been working with other functions during business as usual. They would also add value to the Product Owner role. Chief Executive Officer (CEO): CEOs can be very good Product Owners as they would be having first-hand and complete information about the product, strategy and market trends. The CEO’s experience would be an asset to the Scrum project as they would be constantly thinking about how to achieve a high return on investment, how to engage the customers throughout the Scrum project, etc. All these qualities are already part of the CEO’s roles and responsibilities.  Every individual needs to decide, if they think certifications add value to their career. Certifications are proof of their achievement. Ultimately, it would be their expertise on the job, along with hands-on experience to play the role that matters for career advancement. Individuals can take up a Product Owner certification  To gain knowledge and understanding of the role To refresh their knowledge and get to know the responsibilities and best practices employed by a Product Owner. Why should a PO get certified?    The industry is looking out for Certified Product Owners who can take up the role of a Product Owner in their organizations. The certification is a proof of your achievement, the knowledge you have gained and demonstrates that you would be able to work effectively throughout the Scrum project.  If you are a CSPO certified, your potential employers will be assured that you are the right person for handling the job and the project is in the safe hands.  How can you get CSPO certification?  Attend a live online or classroom course taught by a Certified Scrum Trainer® (CST®), or receive private coaching from a Certified Agile Coach (CAC) in order to get the necessary knowledge and skills to be a successful PO.   Please note, classroom course offers an added value as a lot of doubts can get cleared during the training sessions. If you have attended a training conducted by a Scrum Alliance CST, then on successfully completing the course, you will be asked to accept the CSPO License Agreement and complete your Scrum Alliance membership profile.ConclusionIn this article you learnt who is a Product Owner, and the roles and responsibilities of a PO on a Scrum project. You understood more about CSPO certification and its prerequisites and why a PO should get CSPO certified. You also got to know who all can attend and benefit from the CSPO training.    
Who Should Get CSPO® Certified?
Blogs
9878
Who Should Get CSPO® Certified?

In this article you would learn who is a Product ... Read More

Top Learning Outcomes of Leading SAFe 5 Certification

In any organization, the business decisions made by leaders play an integral role in determining its future. Their mindset, actions and strategies influence the functioning of the organization and workforce. True leaders continuously learn and upskill themselves to be on par with the changing times and stay ahead of the competition. This is where adoption of a Lean-Agile Mindset becomes crucial. It serves as an intellectual and leadership foundation for applying SAFe® principles and practices. A Lean Agile Mindset is undoubtedly the need of the hour for everyone and especially for professionals who oversee a company’s destiny.  This article briefly looks at SAFe® 5.0’s main offering – “Business Agility”, dwells on the foundational competency – “Lean Agile Leadership” and finally talks about how Scaled Agile Inc’s “Leading SAFe®“ course  is one of the front runners in providing knowledge and guidance for building SAFe’s foundational competency in an Enterprise.  What is SAFe®?  Enterprises span across multiple geographical locations, cultures and time zones. External stakeholders like Suppliers and Partners further add on to the organizational milieu. In spite of the scale, the enterprise has to be nimble and agile to keep up with ever changing customer needs and tough competition.Practicing Agile in an Enterprise has its very own challenges because of the scale at which it operates and the high stakes involved.SAFe® is an Agile Framework that recommends ways and methods for enterprises to implement, sustain and improve Lean and Agile Practices. SAFe®1.0 was introduced in 2011 and has evolved into the SAFe®5.0 version which was released in Jan 2020.What is new in SAFe®5SAFe®5.0 introduces quite a few things, of which we look at two important ones- Business Agility and the Dual Operating System.   John Kotter , thought leader of Change Management, famously describes the need for a Dual Operating System that combines the entrepreneurial capability of a network with the organisational efficiency of traditional hierarchy. SAFe® 5 recommends organizing a network around value streams, in addition to the traditional hierarchy, to create a dual operating system to achieve Business Agility.  Image source: Kotter’s Dual Operating SystemImage source: SAFe as a second organizational operating systemBringing agility within Engineering teams may not be enough to create products and solutions that are viable and saleable. Everyone who is involved in building solutions and products – Executives, Senior Leadership, Marketing, Sales, Finance, Engineering, Support, IT, Legal, Compliance, HR- has to be brought into the ambit of Lean and Agile Practices to achieve true Business Agility.The responsibility of making “Business Agility” a reality lies largely with the Leaders of the Organizations.Lean Agile Leadership CompetencySAFe® recommends seven core competencies to become a Lean Enterprise and achieve Business Agility.  “Lean Agile Leadership” is one of the foundational competencies of great significance.Without the buy-in, support and complete conviction from leaders in the organization, the SAFe® implementation cannot happen effectively.  Lean Agile Leaders play a key role in introducing, nurturing and sustaining the SAFe® transformation within the organization.What is required of a Lean Agile Leader?Growth Mindset: Leaders should have a realistic bent of mind to acknowledge a need for change within themselves as well as the organization. The leaders with the right outlook believe in the SAFe Core Values, the Lean-Agile Mindset, and SAFe Principles. Leading By Example: As the famous saying goes, “Actions speak louder than words”. So by walking the talk, leaders can influence scores of people to start adopting the Lean Agile practices, Values and Principles exhibited by themselves. Leading Change: Organizational transformation and change is a very difficult and rocky road to take. There are many thought leaders and researchers producing dedicated models, theories and books for bringing about change and sustaining it. A leader who sets himself on this path is aware of the challenges and is ready to lead the change successfully.   Image Source: Lean Agile Leadership CompetencyOne of the tools for leaders at the helm of bringing about change is having deep rooted knowledge, understanding and purpose about the practices they have to exhibit, and thereby influence the other employees in their organizations.Obtaining the Scaled Agile Framework’s “Leading SAFe®” Certification is the perfect way to start for Lean Agile Leaders. By getting themselves trained, leaders can begin the transformation journey armed with the necessary information.Leading SAFe® Course and CertificationLearning OutcomesThe 2 day long Leading SAFe® course results in the following learning outcomes:The knowledge and principles of Lean, Agile, DevOps, Lean Product Development Insights into achieving Business Agility through organizing around value Understanding of Lean Portfolio Management which emphasizes the need for Lean principles and Lean Budgeting The importance of PI Planning events, co-ordinating Multiple Agile Release Trains, establishing team and technical agility Customer-centric mindset and design thinking approach to Agile product delivery The importance of sustaining SAFe® transformation by creating Communities of Practice and fully empowered employees and teams. In short, the SAFe® Implementation Roadmap helps the leaders to chalk out their organization’s transformation journey. Who should take the Leading SAFe® Course? This course is just right for leaders who are in a position to influence employees, organizational structure and the future of products / solutions.  Executives of the organization that decide on the future course of business Business Unit Heads who are responsible for a Portfolio Heads of functions like Marketing/Sales/Product/IT/Engineering etc Agile Program Managers and Project Managers who steer programs and projects, Managers of teams Technology leaders like Enterprise and Solution Architects/ Distinguished Engineers/ Fellows who command a large sphere of influence on teams Leading SAFe® CertificationAttending the 2 day Leading SAFe® course is a requirement to write the exam, and participants will get access to all the study materials and the exam. Once the exam is   successfully completed, the candidate gets the below privileges as per Scaled Agile, Inc. Certified SAFe® Agilist PDF certificate Certified SAFe® Agilist digital badge to promote your accomplishment online One-year membership to the SAFe Community Platform, which includes access to the SA Community of Practice Access to Meetup groups and events that connect you with other SAFe certified professionals A variety of learning resources to support you during your SAFe journey Benefits of taking Leading SAFe®5 trainingEvery change starts with – what is in it for me? The Leading SAFe® course outlines a generic framework that is applicable to any enterprise. For an individual employee it is a learning for life and can be applied to any organization he/she is associated with.  The SAFe® Agilist Course and Certification is one of the prestigious achievements in the individual’s professional life earning him/her respect and recognition within the Agile Community.           A SAFe®5 certified professional is eligible for better prospects within their own organization or in other organizations, if and when there is a need for job change.  According to Forrester’s Q2 2015 Global Agile Software Application Development Online Survey-“The Scaled Agile Framework (SAFe®) is the most widely adopted enterprise Agile approach according to most survey data, with 33% using it”. With more than 70% of US Fortune 100 companies actively employing SAFe®, it is clear that the demand for Leading SAFe® is on a constant rise. Benefits of Leading SAFe®5 Training for the organization:Leadership is the foundation on which the “House of Lean” is built. A strong foundation of Lean Agile leaders, Managers and Executives help to create a learning culture for the organization by exhibiting the Lean Agile Mindset. This, in turn, paves the way for enterprise-wide transformation. Having a strong army of Agilists that are trained and certified helps the organization to sustain the principles of Lean and Agile.Agile ManifestoCorporate training for the leaders of the organization from a reputed Training provider like Knowledge Hut will ensure that all leaders are on the same page, hearing the same message at the same time. The training will become an opportunity for collaboration and the discussions during the training facilitated by the trainer can be tailored to suit organizational needs.   Why KnowledgeHut for Leading SAFe®5 Course?KnowledgeHut is a leading training provider offering a variety of accredited training programs for Corporates and Individuals. KnowledgeHut is a preferred training partner for various corporates.  KnowledgeHut offers training across 70 countries in over 250 industry-recognized courses. This includes a wide range of Courses in Agile and SAFe®.  Scaled Agile, Inc is the only certifying authority for SAFe® and KnowledgeHut is a Silver Partner of Scaled Agile, having trained more than 4000 professionals in various SAFe® certifications.  The Trainers for Leading SAFe® courses are an elite panel of accredited SPCs who also have years of experience as active SAFe® practitioners.  Learning happens through experiential workshops by accredited industry experts who bring in vast real-world experience imparting knowledge through in-class activities and simulations. Please refer here for all the details and the value-added services offered by KnowledgeHut for the “Leading SAFe® 5 “course. In conclusion, Scaled Agile Inc’s Leading SAFe®5 from KnowledgeHut will be a unique learning experience that will set the stage for success in one’s professional life. This credential benefits equally the individual, the organization and the larger cause of increasing the number of Agilists and improving the Agile Community at large.
Top Learning Outcomes of Leading SAFe 5 Certification
Blogs
6642
Top Learning Outcomes of Leading SAFe 5 Ce...

In any organization, the business decisions made b... Read More

Why Do We Use Fibonacci Series for Estimation

In this article, my focus is on sharing my experience as a Trainer/Mentor/Coach to Agile teams with respect to Agile estimations; and on using the Fibonacci sequence as scale to size the Story. What will you learn in this article? Agile practitioners mostly use Story points as a measure for estimation, typically using the Fibonacci scale. In this article we are going to understand the top reasons why we use the Fibonacci series for estimation, and how it works in practice. Before we get to the details, let us try to understand some of the fundamentals. Why do we need to estimate?Estimates help the project team to: Identify the time & effort required to arrive at the project schedule Identify the right number of people required to do the work Arrive at the budget by rolling up the cost of all activities required to complete the work; and Prioritize the work in conjunction with the value that will be delivered. Some software developers fear to provide effort estimates as they are accountable to complete their work within the time.  Hence, they take so much time to get into the details to make sure they have enough information to provide the estimates. This sometimes may not be possible during the beginning of the project as the team may not have enough information on hand to provide the effort estimates for all the tasks to be performed. Hence the order of magnitude (ROM, Budget or Definitive) will be applied at various stages during the project based on the available information to predict the effort needed to complete the activities. Agile Estimation  Typically, in traditional project management, effort estimations may or may not be agreed upon by the entire team. Estimates may either be given by the Project Manager/Tech Lead to the team or the developers/testers may estimate for the piece of work that they have been assigned. This way of estimating a project does not provide an opportunity for the team to collaborate. There may be a difference of opinion with the team members in the effort that need to be spent on an activity. The way the estimations are done within an Agile team is little different. It is just not about the measure used to estimate the effort (for example Story Points), but ensures that the team collaborate among themselves, thus providing an opportunity for knowledge sharing. This helps the accuracy of the estimates when compared to doing individual vs group estimates as the team members come from different backgrounds and roles (developers, testers, quality analysts, business analysts). An Agile team effort estimate focuses on relative sizing of user stories and does not focus on the duration; hence it is faster. The team learns to size the story relatively and accurately over a period of a few iterations (sprints), thus improving the predictability (arrived through establishing consistent velocity over a period of few iterations) as well.  Planning Poker is commonly used as the planning exercise for the team to collaborate and size the stories. Planning Poker uses Fibonacci sequence to assign a value to the epic/feature/story. What is Fibonacci Series?  According to Oxford dictionary, Fibonacci Series is : “ a series of numbers in which each number ( Fibonacci number ) is the sum of the two preceding numbers. The simplest is the series 1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, 144 etc” The formula to arrive at a Fibonacci sequence is: Xn = Xn-1 + Xn-2 This sequence will be slightly modified when used in Agile estimations: typically, it will not have values beyond 100 and may have 0, ½, 1, 2, 3, 5,8, 13, 20, 40, 100. Some teams limit the highest value as 21 and use 0, 1/2, 1, 2, 3, 5, 8, 13, 21. Top 3 Reasons Why Using the Fibonacci Sequence Will Make You Better at Estimating Tasks  1. Weber–Fechner law: “The Weber–Fechner law refers to two related hypotheses in the field of psychophysics, known as Weber's law and Fechner's law. Both laws relate to human perception, more specifically the relation between the actual change in a physical stimulus and the perceived change. This includes stimuli to all senses: vision, hearing, taste, touch, and smell” Applying the law to Numerical Cognition,  “Psychological studies show that it becomes increasingly difficult to discriminate between two numbers as the difference between them decreases. This is called the distance effect. This is important in areas of magnitude estimation, such as dealing with large scales and estimating distances. It may also play a role in explaining why consumers neglect to shop around to save a small percentage on a large purchase, but will shop around to save a large percentage on a small purchase which represents a much smaller absolute dollar amount”  (source: https://en.wikipedia.org/wiki/Weber%E2%80%93Fechner_law) The Fibonacci sequence very well corresponds to Weber’s law. The values in the Fibonacci sequence are about 60% higher than the previous value, and hence applying relative sizing is much easier. It is very challenging to distinguish the size of two numbers which are adjacent to each other, by just looking at the objects. Let us take an example of a football and cricket ball. The approximate diameter of a cricket ball would be 2.8 to 2.86 inches whereas the diameter of a football would be 8.66 inches. It is easy to distinguish the relative size of these two (i.e., approximately the diameter of a football is 3 times that of a cricket ball). However, it is very challenging to distinguish between two cricket balls that vary 1 inch in diameter, unless you measure both. If you look at the Fibonacci sequence, the relative size between two adjacent numbers is more than 60% and this helps us to be able to size them accordingly.   2. Reflect Uncertainty The smaller value assigned from the Fibonacci sequence to a user story usually means that the story is well understood, and the user story follows INVEST (Independent, Negotiable, Valuable, Estimable, Small and Testable) guidelines. Whereas the largest value denotes the story is not well understood or it needs to be broken down further. Smaller stories can be confidently estimated by the team in detail. A general practice from matured Agile teams is that the Fibonacci sequence is restricted up to 21 (0,1,1,2,3,5,8,13,21) and any story which is of size beyond 21 will have to be broken down further. This ensures that the team is not giving any room for greater uncertainty and good practice for the team to write better stories under the INVEST guidelines. 3. Comparison Though it is not mandatory to use Fibonacci sequence for story point estimations, the sequence is easier to understand and adoptable by the team. Individuals are better at comparison than estimation.  The easy sequence and distinguishable values of Fibonacci sequence helps to estimate by not measuring the objects but by comparison. How Does Fibonacci Agile Estimation Work in Practice?  When do you think is the right time for the Agile team to estimate user stories that are prioritized by the Product Owner in the product backlog? In my experience, I would say that the estimates (story point sizing) should happen during the Iteration/Sprint backlog grooming sessions. This gives the team the time to go through the user stories in detail, collaborate and mutually agree using the Planning Poker exercise.  Then what do we do in Sprint Planning? – This ceremony should be used to pick the stories from the product backlog (fulfils Definition of Ready), that can be completed within the iteration/sprint and then breakdown the stories into tasks and do one more level of estimation which is effort estimation denoted in hours. Let us say a team is assigned a task to estimate a reporting module to be developed: The team would agree that it is a difficult task to provide an effort estimation and it would take a longer time to complete; but how long will it take? Using Simple, Medium and Complex categorization would simply mean that the estimate falls into the Complex category; but how complex is it? Breaking down the requirement into granularized tasks, getting to the minute details and then arriving at an effort estimation would be a complex process and time consuming as well. Can the team take linear sequence (1,2,4,8,10,12,14,16….) and size them for a high-level estimation? Is it possible to size between 50 and 52? What can be defined as the highest scale? Using Fibonacci series helps the team to size the stories which have a distinguishable value and as discussed earlier, matured Agile teams use modified Fibonacci series and have highest scale of 21 to size a story. As discussed above, the Fibonacci numbers are 60% above than the previous number, and that helps in relative sizing. Summary There are various methods to estimate user stories, like T-Shirt sizing, Dot voting, Affinity Mapping etc. Story points is the widely used measurement for sizing the user stories. Fibonacci series helps the team to compare between two stories; and its very nature of distinguishable values helps them to fit the story into the right size that reflects uncertainties, which further helps the team to refine the story to remove those uncertainties. Hope this article was useful to you.
Why Do We Use Fibonacci Series for Estimation
Blogs
5985
Why Do We Use Fibonacci Series for Estimation

In this article, my focus is on sharing my expe... Read More

PRINCE2®Agile vs PMI-ACP®: What’s Best for You?

Changing industrial trends and the mass adaptability of agile practices have transformed the way organizations work. Over time, a number of project management methodologies have cropped up to suit different industry needs, and today’s business leaders have a wide array of frameworks to rely upon. This has led to the inevitable need for skilled project management professionals who are well-versed in different frameworks. When it comes to the widely popular Agile methodologies, the presence of multiple certifications in agile / agile project management methods can seem overwhelming to aspiring professionals. This article will give you a comprehensive overview of PRINCE2®Agile and PMI-ACP® (Agile Certified Practitioner) certifications to help you make an informed choice. Project leadingWhat is a Project? Due to the accelerated pace of change, today’s enterprises have to cope with the complexities of emergent requirements over the course of a project. Strategic business decisions are often made after taking stock of competitors’ actions, technological advancements, regulatory changes, ongoing business developments and so on. In order to compete and thrive in the future, existing ways of working must be aligned to adapt to these evolving needs. Example: Today every bank across the globe offers innovative banking products and services like mobile banking applications, ATMs etc. These changes have been adopted to cater to the evolving expectations of customers while adapting to the latest technological advancements. Projects are the means of introducing change. A collective effort from different stakeholders needs to be pumped into the project initiatives to deliver the products and to accomplish the objectives within definitive timescales. Example: The Ministry of Health & Family Welfare of a country is planning to design, build, roll-out and implement a Health ID card system for its citizens within a year. This project will benefit the government and its citizens in various ways. Different organizations such as government, health ministry, hospitals, technology providers have to work collaboratively to implement the product within the identified timescale, cost and quality. Project Manager planningWhat is Project management? When different stakeholders come together to deliver a unique product within an estimated timescale and cost, there should be someone who needs to be accountable and responsible to manage the different aspects of the project.  Project management broadly revolves around key activities such as plan, execute, monitor and control. Management of projects is an art which includes skills like leadership, domain knowledge, interpersonal skills, people management, powerful communication, stakeholder engagement, conflict management, business acumen etc.,  Example: A central library run by a private firm is looking to launch a digitized version of its books. A Project Manager is identified to manage the scope, cost, time, quality, risks, resources, stakeholders, communications etc., from the beginning to the end of the project.  Project managers and their organizations can choose to apply the right methods, tools, techniques, standards, guidance, good or best practices to run their projects.  Why agile in project management?  As digital transformation is catching up with many organizations, business demands are also increasing, and the requirements for products and services is continually evolving as well. To meet the demands of businesses today, project-driven organizations should look for ways to increase the speed of product delivery while upholding quality. Agile project management is an iterative approach to delivering a project throughout its life cycle. The Agile framework helps project managers to stay on top of emergent requirements and adapt to change more readily, delivering products that are better aligned with customer expectations. With agile methods such as Scrum being widely accepted and used in today’s organizations for software development projects, more agility is seen in the delivery teams. Product development in Scrum teams occurs in shorter iterations/timeboxes (2 weeks to 4 weeks). This is because the goal is to deliver minimum viable products (MVP) or a feature/functionality within shorter sprints. Example: As a part of digital transformation, a school wants to launch a mobile app. In the beginning of the academic year, the first section of the app was ready and launched for use. During the launch, it only had a login and a digital diary feature. In the second month, they added a few more features such as timetable, attendance tracker. In the third month, new enhanced features such as progress card, online payment options were added. By the end of six months, the app had varied features to suit the needs of the school, teachers, students and parents and it added value to all categories of stakeholders iteratively.  The Contrast of Waterfall Vs. Agile ways of working:The Contrast of Waterfall Vs. Agile ways of working:The reason for agile’s popularity is because of its ability to address the new demands being placed on the project team.  Prince2 ProcessesWhat is PRINCE2®? PRINCE2® (PRojects IN a Controlled Environment) is widely considered the leading project management method. It is a unique, light weight, scalable, flexible, highly tailorable, principle-driven, agile enabled framework to run your projects.  PRINCE2 revolves around the concepts of principles (value statements), themes (focus areas to run the project) and processes (steps involved to accomplish project objectives).  Let’s get introduced to the PRINCE2 elements: Principles: Continued business justificationBusiness valueLearn from experienceLessons are sought, recorded and acted upon; continuous improvementDefined roles and responsibilitiesAll stakeholders representedManage by stagesProvides management control and realistic planning horizonsManage by exceptionAuthority delegation for directing, managing and delivering within tolerancesFocus on productsQuality-centric approach to planningTailor to suit the projectTailor to suit project environment, size, complexity, importance, risk, etc.Themes:Business CaseWhy?OrganizationWho?QualityWhat?PlansHow?, How much?, When?RiskWhat’s the impact?ProgressWhere are we now?Where are we going?Should we carry on?Processes:Starting Up A ProjectVerify whether the project is worthwhile and viable.Directing A ProjectDecision making, allocation of resources and estimating expenditure.Initiating A ProjectSetting up a firm foundation (controlled environment) for the project.Managing Stage BoundariesPreparation for management review including stage planning.Controlling A StageDay to day management of the work, issues and risk.Managing Product DeliveryProduct creation, delivery and acceptance.Closing A ProjectFinal delivery, acceptance and project evaluation.PRINCE2® Process Flow Diagram:PRINCE2® Process Flow Diagram:Processes are at the core of the PRINCE2 framework. Application of themes, principles and tailoring of the processes makes it easy to adopt and adapt which reduces the bureaucracy of project management. At the same time, it provides the proper governance to keep the projects justified.What is covered in PRINCE2 Agile™?Project EnvironmentIf PRINCE2® is already agile, what is PRINCE2 ® Agile? PRINCE2® Agile guidance is all about tailoring PRINCE2 to incorporate Agile methods. PRINCE2 is a neutral project management framework which can support both traditional waterfall projects as well as agile or adaptive or iterative projects.  To provide guidance on how to integrate high velocity models or practices into the existing projects for both IT and non-IT industries, PRINCE2 Agile considers Scrum, Kanban, Lean approaches. The intention is not to explain all the agile frameworks in detail; but rather is to show practitioners how to amalgamate PRINCE2 with other agile practices. PRINCE2 considers agile as a collection of behaviours, concepts, frameworks and techniques.   In a nutshell, PRINCE2® Agile is basically a marriage between PRINCE2 and Scrum practices.  PRINCE2’s core concepts of principles, themes and processes are tossed up with agile concepts, techniques, behaviours, practices which fuels more velocity into the existing framework.Certification: PRINCE2® Agile has two levels of certification (Foundation and Practitioner) Foundation Exam: Multiple choice 50 questions 1 hour to complete the paper Achieve 28 or more out of possible 50 marks (55%) to pass the exam Closed book exam Practitioner Exam: Multiple choice 50 questions based on project scenario 2 hours 30 minutes to complete the paper Achieve 30 or more out of possible 50 marks (60%) to pass the exam Open book exam. You can use the “AXELOS® PRINCE2 Agile™ guidance book”.  Certification Scheme: Prior project management experience is not required to take up the certification.  What is covered in PMI-ACP®? The Project Management Institute’s Agile Certified Practitioner is a credible certification which provides thorough knowledge to project managers using agile methodologies.  There are many agile practices other than Scrum that are widely used in the industry such as eXtreme Programming, DevOps, Test Driven Development (TDD), Behaviour Driven Development (BDD), Feature Driven Development (FDD), Crystal, Scaled Agile Framework (SAFe), Disciplined Agile Delivery (DAD), Dynamic Systems Development Method (DSDM), Kanban, Lean Product Development etc., Most of these practices revolve around the core concept of iterations with other variations. Most of these practices are ‘IT-only’ frameworks.  Agile mindset and principles play a vital role in executing the projects in a different way as compared to the traditional ways. Right from covering the concepts of agile values, mindset, practices, terminologies, most of the above-mentioned agile models are covered in a greater detail in this program.  Concepts and techniques like agile contracting, agile risk management, earned value management (EVM), cumulative flow diagrams (CFD), estimation techniques, relative prioritization, work in progress (WIP) limits, Kano analysis, product backlog grooming, personas, user stories, story maps, wireframes, product road map, minimum marketable feature (MMF), definition of done, continuous integration, burn charts, stakeholder engagement, leadership, building agile teams, coaching, osmotic communication, timeboxing, planning poker, release planning, problem solving, lead time, cycle time, defect rate, control limits, throughput, velocity, variance and trend analysis, value stream mapping, continuous improvement, retrospectives, learning cycles etc., are imparted as a part of this certification course.Certification: 120 Multiple choice questions 3 hours to complete the exam Closed book exam Prerequisite: Secondary degree 21 contact hours of training in agile practices 12 months of general project management experience within 5 years.  8 months of agile project management experience within the last 3 years. Differences in these certifications:ParametersPRINCE2 AgilePMI-ACPTopics coveredIt is a blend of  PRINCE2® and Scrum.Spans across many approaches of agile.Governing bodyAxelosProject Management InstituteExam bodyPeoplecertPearson VUEExam modePaper-based test, computer-based test and Online proctored examOnline proctored examPrerequisiteNo prior project management experience is required. PRINCE2 Foundation or PRINCE2 Agile foundation certification is a prerequisite for taking up the practitioner exam.Secondary degree21 contact hours of training in agile practices12 months of general project management experience within 5 years.  8 months of agile project management experience within the last 3 years.Training4 days of training from an Accredited Training Organization (ATO) by Axelos3 days of training from a Registered Training Partner (REP) by PMICost of training & certificationApproximately Rs. 40,000 to 50,000Approximately Rs. 40,000 to 50,000Maintaining the certificationFoundation certification has a life time validity. Practitioners need to earn 20 continuing professional development (CPD) points every year.Earn 30 professional development units (PDU) every three years.Merits and demerits of both these certifications: Merits of PRINCE2® Agile:  PRINCE2 Agile provides a good governance model to run the project with guidance on how to incorporate any agile model.  It does not favour one agile approach over any other although Scrum is taken as a reference to explain the concept of tailoring.  It can be applied to any type of project and can easily be implemented alongside specialist, industry-specific models.  Demerits of PRINCE2® Agile:  It does not touch upon the various project management tools or techniques which are essential for project management. Merits of PMI-ACP®: It prepares the project managers to become versatile with different types of agile project management practices. Coverage of different types of tools and techniques polishes one’s ability to manage scope, cost, time, quality, risks, resources, stakeholders, communication etc. Demerits of PMI-ACP®: It does not have an exclusive body of knowledge (BOK) like PMBOK® guide. Reference to different literature and books may be essential. This means a structured way to agile project management is missing in its approach.  The best-suited certification: How to pick the right one? PRINCE2® Agile can benefit the existing PRINCE2® community, PRINCE2® Practitioners, anyone who is using agile in Project Management. Even organizations and individuals outside the PRINCE2® community, having experience with agile can benefit from this certification. It is also ideal for total novices. If you fall under any of the categories mentioned above, you can pick this certification as your first step in the project management world. This is also the right choice for professionals and enterprises that serve clients based in UK, Europe and Australia. PMI-ACP is a one-stop solution for project managers and agile teams keen on expanding their skill-set to manage various agile projects. If you are ready to dedicate at least 2 hours every day for 1 to 2 months for exam preparation and earn a globally recognized certification, go for it.  Conclusion: Every practice has its own strength and weakness. Ultimately, it is up to the organizations and practitioners to choose the right project management methodologies to suit their needs and business/career goals.  
PRINCE2®Agile vs PMI-ACP®: What’s Best for You?
Blogs
5999
PRINCE2®Agile vs PMI-ACP®: What’s Be...

Changing industrial trends and the mass adapta... Read More