Search

Non-Functional Requirements

In this article, we will see what non-functional requirements are, and how they are elicited and captured in agile projects. You will understand the concepts through a few examples, and get to know the difference between functional & non-functional requirements. The impact of non-functional requirements in solution development is discussed, together with the implementation approach.  Understand the concepts of non-functional requirements through a few examples, and their impact in solution development What is Non-Functional Requirement? “In systems engineering and requirements engineering, a non-functional requirement (NFR) is a requirement that specifies criteria that can be used to judge the operation of a system, rather than specific behaviours. They are contrasted with functional requirements that define specific behaviour or functions. The plan for implementing functional requirements is detailed in the system design. The plan for implementing non-functional requirements is detailed in the system architecture, because they are usually architecturally significant requirements” Source.While functional requirements define “what” the system should do, non-functional requirements define operational capabilities and constraints that enhances the functionality and “how” the system should do it. They specify quality attributes of a system. A Guide to the Business Analysis Body of Knowledge® (BABOK® Guide v3) describes non-functional requirements as requirements that “do not relate directly to the behaviour of functionality of the solution, but rather describe conditions under which a solution must remain effective or qualities that a solution must have” (p. 16)  How to Elicit Non-Functional Requirements? When the business analysts elicit requirements from the stakeholders on the functional aspects of the system, they also should understand from the stakeholder what attributes the system should provide in order to meet their business goals. For example, the website must be able to load within 0.5 seconds. Eliciting a non-functional requirement is more challenging than the functional requirement, as the stakeholders/users are good at articulating the functional requirements well; while they may not be aware of, or good at explicitly stating non-functional requirements. Business analysts will have to get these requirements from stakeholders by asking the right questions. NFRs are implicit by nature, meaning that people assume them to exist without being asked. Some of the questions to be prompted that may help the business analyst to ask stakeholders how they want their system to function include the following aspects: Performance – speed of the system e.g., response time, throughput etc Availability – what is the impact if the system is not available for the customer? Security – ensuring unauthorized access to the system Data Retention - how long should the data be retained in the system for reference? This could be a regulation from the government/country. Usability – easy access for the customer/user while using the system Stability – code/system stability when dynamic changes apply due to business needs Compliance – understanding compliance needs by local laws/regulations Reliability – probability of system performing without failure Recoverability – ability of the system to recover from failure Serviceability – ease of system service when necessary Data integrity – accuracy and correctness of data maintained in the system Scalability – ability of the system to scale when more resources are added Capacity – how much the system can store information Accessibility - how easily people with the widest range of capabilities can use the system. Non-Functional Requirements in Agile A common challenge for an Agile team is dealing with capturing non-functional requirements in a user story. The non-functional requirements can be written as a user story and made available in the product backlog or sprint backlog.  For example, “As an ecommerce website user, I want the website to be available for 99.99999%, so that I purchase products whenever I feel like” NFR can also be included as Acceptance Criteria in a user story. For example, for the following user story, “As an ecommerce website user, I want to search for products, so that I can purchase them”. NFR as acceptance criteria would be “application responds to search request within 5 seconds from the time request is received”. Examples of Non-functional requirements Some of the typical non-functional requirements considered during system development are: Performance – funds transfer transaction should not take more than 0.5 seconds Availability – the system should be available for the users to use the system anytime of the week they need Security – payroll data is not visible to all the employees in the organization. Only the authorized personnel should have access to the data Data Retention – all healthcare data should reside in the system for 7 years. Older data can be archived and should be accessible when required Usability – the system navigation is easy for the end user and provides a seamless journey while accessing the system Stability – the code/system is stable when new changes are applied due to dynamic business needs Compliance – HIPAA compliance should be adhered when dealing with patients’ data in USA Reliability – website users should be able to access the system 99% of the time without any failure Recoverability – In case of any major failures, the system should be restored within 48 hours Serviceability – the system should be serviceable immediately when there is a failure Data integrity – the system should not allow phone number to be entered in the data field Capacity – the system should be able to store 1 million records of basic customer information Scalability – the system should be scalable to support unlimited growth of the employees Accessibility - The system shall be accessible to people with disabilities in accordance with the Americans with Disabilities Act  Confidentiality – The system shall not display the bank account number in full. It should display only the last 4 digits of the account number while others can be masked Efficiency – The interface between the system and user should not take more than 2 seconds Portability – The system shall be developed for both windows and Mac operating systems platforms  Functional vs Non-Functional RequirementsS. NoFunctionalNon-Functional  1Defines ‘What’ of the customer requirementsDefines ‘How’ of the customer requirements2Elicited by business analysts, specified by the customerDefined by technical team like architects, developers etc3Documented as the requirements document by the business analystDocumented as the technical document by the team4Defines the functionality in the systemDefines quality attribute in the system5Captured as a user story in agileCaptured either as a story or part of acceptance criteria of a user story6Customer tests and validates the functionality as specified by themCustomers cannot test these quality attributes, however, can experience while using the system7Customers find it easy to define theseIt is hard to define by the customer8Defines the product featuresDefines the product propertiesThe Impact of NFRs on Solution Development  The business analyst and the project development team understand the customer requirements and expectations well and they are comfortable in converting the requirements into a finished product. Customer also validates the functional part of the requirements and signs off on successful implementation. However, the project success is dependent on the non-functional requirements as they define the quality attributes of a system.  Some or all of the types of non-functional requirement that is described above contributes towards the successful implementation of the system. For example the system should be available all the time with minimal or negligible downtime, security is not compromised, maintaining confidential data/information, not allowing unauthorized users, scalable while the customer business is growing, having enough capacity to maintain product data considering future growth etc. Failure of any of these quality attributes will leave the customer unsatisfied.  Implementation Approaches  In general, the focus of the project team is to provide the functionality that the user has given. The non-functional requirements are looked into towards the end of the project after the customer UAT is complete. The team then focusses on the non-functional quality attributes, and sometimes may not be able to fulfil them as the design of the system may not accommodate the respective implementation. It is good to see the trade-off between the quality attributes during the requirements and early in the design stage of the project. Defining the non-functional requirements needs thorough analysis and creativity in the early stages. It is recommended to consider this during the development life cycle of the software development, rather than leaving this to be discussed at the later stage of the project.  As seen earlier, the elicitation of the non-functional requirements can be carried out by the business analyst by using the prompt list and added as part of the requirements document in the traditional project management. These requirements can be specified either as a user story or part of the acceptance criteria of a user story, which enables the team not to miss any of these during the development stage, without leaving it to the end of the project life cycle. ConclusionSuccessful implementation of a system depends on the non-functional attributes and their behaviour during the lifecycle. It is important to elicit or identify these quality attributes at the beginning of the system development cycle. 
Non-Functional Requirements
Krishnakumar
Krishnakumar

Krishnakumar Kuppusamy

Author

Krishnakumar Kuppusamy is one of the highly experienced Agile Coaches and SAFe Program Consultant (SPC 5.0). He has 24+ years of experience in information technology industry handling both traditional and agile projects. He has worked with companies like Citibank (USA) & Polaris Software at various capacities in project & program management. 

He has worked for ANZ and Ford India, coaching multiple Agile teams in their transformational journey. He is also a freelance trainer, conducted trainings in SAFe/PMP/PMI-ACP/ITIL/CBAP for over 2000+ professionals helping them getting certified and excel in their respective areas. 

Posts by Krishnakumar Kuppusamy

Non-Functional Requirements

In this article, we will see what non-functional requirements are, and how they are elicited and captured in agile projects. You will understand the concepts through a few examples, and get to know the difference between functional & non-functional requirements. The impact of non-functional requirements in solution development is discussed, together with the implementation approach.  Understand the concepts of non-functional requirements through a few examples, and their impact in solution development What is Non-Functional Requirement? “In systems engineering and requirements engineering, a non-functional requirement (NFR) is a requirement that specifies criteria that can be used to judge the operation of a system, rather than specific behaviours. They are contrasted with functional requirements that define specific behaviour or functions. The plan for implementing functional requirements is detailed in the system design. The plan for implementing non-functional requirements is detailed in the system architecture, because they are usually architecturally significant requirements” Source.While functional requirements define “what” the system should do, non-functional requirements define operational capabilities and constraints that enhances the functionality and “how” the system should do it. They specify quality attributes of a system. A Guide to the Business Analysis Body of Knowledge® (BABOK® Guide v3) describes non-functional requirements as requirements that “do not relate directly to the behaviour of functionality of the solution, but rather describe conditions under which a solution must remain effective or qualities that a solution must have” (p. 16)  How to Elicit Non-Functional Requirements? When the business analysts elicit requirements from the stakeholders on the functional aspects of the system, they also should understand from the stakeholder what attributes the system should provide in order to meet their business goals. For example, the website must be able to load within 0.5 seconds. Eliciting a non-functional requirement is more challenging than the functional requirement, as the stakeholders/users are good at articulating the functional requirements well; while they may not be aware of, or good at explicitly stating non-functional requirements. Business analysts will have to get these requirements from stakeholders by asking the right questions. NFRs are implicit by nature, meaning that people assume them to exist without being asked. Some of the questions to be prompted that may help the business analyst to ask stakeholders how they want their system to function include the following aspects: Performance – speed of the system e.g., response time, throughput etc Availability – what is the impact if the system is not available for the customer? Security – ensuring unauthorized access to the system Data Retention - how long should the data be retained in the system for reference? This could be a regulation from the government/country. Usability – easy access for the customer/user while using the system Stability – code/system stability when dynamic changes apply due to business needs Compliance – understanding compliance needs by local laws/regulations Reliability – probability of system performing without failure Recoverability – ability of the system to recover from failure Serviceability – ease of system service when necessary Data integrity – accuracy and correctness of data maintained in the system Scalability – ability of the system to scale when more resources are added Capacity – how much the system can store information Accessibility - how easily people with the widest range of capabilities can use the system. Non-Functional Requirements in Agile A common challenge for an Agile team is dealing with capturing non-functional requirements in a user story. The non-functional requirements can be written as a user story and made available in the product backlog or sprint backlog.  For example, “As an ecommerce website user, I want the website to be available for 99.99999%, so that I purchase products whenever I feel like” NFR can also be included as Acceptance Criteria in a user story. For example, for the following user story, “As an ecommerce website user, I want to search for products, so that I can purchase them”. NFR as acceptance criteria would be “application responds to search request within 5 seconds from the time request is received”. Examples of Non-functional requirements Some of the typical non-functional requirements considered during system development are: Performance – funds transfer transaction should not take more than 0.5 seconds Availability – the system should be available for the users to use the system anytime of the week they need Security – payroll data is not visible to all the employees in the organization. Only the authorized personnel should have access to the data Data Retention – all healthcare data should reside in the system for 7 years. Older data can be archived and should be accessible when required Usability – the system navigation is easy for the end user and provides a seamless journey while accessing the system Stability – the code/system is stable when new changes are applied due to dynamic business needs Compliance – HIPAA compliance should be adhered when dealing with patients’ data in USA Reliability – website users should be able to access the system 99% of the time without any failure Recoverability – In case of any major failures, the system should be restored within 48 hours Serviceability – the system should be serviceable immediately when there is a failure Data integrity – the system should not allow phone number to be entered in the data field Capacity – the system should be able to store 1 million records of basic customer information Scalability – the system should be scalable to support unlimited growth of the employees Accessibility - The system shall be accessible to people with disabilities in accordance with the Americans with Disabilities Act  Confidentiality – The system shall not display the bank account number in full. It should display only the last 4 digits of the account number while others can be masked Efficiency – The interface between the system and user should not take more than 2 seconds Portability – The system shall be developed for both windows and Mac operating systems platforms  Functional vs Non-Functional RequirementsS. NoFunctionalNon-Functional  1Defines ‘What’ of the customer requirementsDefines ‘How’ of the customer requirements2Elicited by business analysts, specified by the customerDefined by technical team like architects, developers etc3Documented as the requirements document by the business analystDocumented as the technical document by the team4Defines the functionality in the systemDefines quality attribute in the system5Captured as a user story in agileCaptured either as a story or part of acceptance criteria of a user story6Customer tests and validates the functionality as specified by themCustomers cannot test these quality attributes, however, can experience while using the system7Customers find it easy to define theseIt is hard to define by the customer8Defines the product featuresDefines the product propertiesThe Impact of NFRs on Solution Development  The business analyst and the project development team understand the customer requirements and expectations well and they are comfortable in converting the requirements into a finished product. Customer also validates the functional part of the requirements and signs off on successful implementation. However, the project success is dependent on the non-functional requirements as they define the quality attributes of a system.  Some or all of the types of non-functional requirement that is described above contributes towards the successful implementation of the system. For example the system should be available all the time with minimal or negligible downtime, security is not compromised, maintaining confidential data/information, not allowing unauthorized users, scalable while the customer business is growing, having enough capacity to maintain product data considering future growth etc. Failure of any of these quality attributes will leave the customer unsatisfied.  Implementation Approaches  In general, the focus of the project team is to provide the functionality that the user has given. The non-functional requirements are looked into towards the end of the project after the customer UAT is complete. The team then focusses on the non-functional quality attributes, and sometimes may not be able to fulfil them as the design of the system may not accommodate the respective implementation. It is good to see the trade-off between the quality attributes during the requirements and early in the design stage of the project. Defining the non-functional requirements needs thorough analysis and creativity in the early stages. It is recommended to consider this during the development life cycle of the software development, rather than leaving this to be discussed at the later stage of the project.  As seen earlier, the elicitation of the non-functional requirements can be carried out by the business analyst by using the prompt list and added as part of the requirements document in the traditional project management. These requirements can be specified either as a user story or part of the acceptance criteria of a user story, which enables the team not to miss any of these during the development stage, without leaving it to the end of the project life cycle. ConclusionSuccessful implementation of a system depends on the non-functional attributes and their behaviour during the lifecycle. It is important to elicit or identify these quality attributes at the beginning of the system development cycle. 
8965
Non-Functional Requirements

In this article, we will see what non-functional... Read More

SAFe Release Planning- Know Your Capacity Constraints

As an Agile Coach in a Scaled Agile Framework® (SAFe®) implementation environment, I have, to the best of my knowledge, explained about the capacity constraints that need to be considered during the Program Increment Planning. In this article let us focus on how the key event in Scaled Agile Framework (SAFe), known as Program Increment (PI) is conducted and understand how recognizing the underlying capacity constraints helps the team plan and commit better. Release Planning – Agile Team: Release planning is a process where the Agile team along with Scrum Master, Product Owner and key stakeholders collaborate to deliver a product increment at regular intervals - typically 2 to 3 months. The Product Owner shares the vision to the team along with a prioritized list of Features that he/she feels can be included in the release. The Agile team works together in splitting the Features to User Stories, estimating Size, and discussing issues & concerns with the Product Owner. They highlight risks, tentatively park the stories across iterations based on the historical velocity that the team can achieve and then arrive at & commit to the release schedule.   Program Increment in SAFe Release Planning in Scaled Agile Framework is a two-day timeboxed event and is called a Program Increment.  “Program Increment (PI) Planning is a cadence-based event that serves as the heartbeat of the Agile Release Train (ART), aligning all the teams on the ART to a shared mission and Vision. PI planning is essential to SAFe: If you are not doing it, you are not doing SAFe” –  Scaled Agile Inc., Why PI Planning? This focussed and dedicated two-day event brings together the entire Agile Release Train(s) into a common forum and more importantly imforms every individual in the train towards the alignment of development to business goals with the business context, program objectives and to understand the direction of the business. The PI planning event corroborates multiple teams within and across ART(s) to discuss, empathize and structure the flow of work that can be taken up for the upcoming PI duration (typically 8 to 12 weeks). PI planning establishes face to face communication of all the team members and stakeholders and also matches demand to capacity by eliminating excess Work in Progress(WIP). PI Planning MeetingImage SourceLet us look briefly at the sequence of activities that are involved in the 2-day Program Increment event. Pre-work: Epics broken down into Features Value (outcome) identified for each feature, analysed and prioritized (example using WSJF) Approximately top 10 features identified for the upcoming PI Day 1 Agenda: Business context set by the business owner Product solution goals set by the product management team Technical/Development goals set by the technical architect team RTE setting the Planning context and agenda Teams breakout to break the features into stories, estimate (story point sizing), determine capacity and load for each iteration, identify risks and dependencies within & across ART(s) and submit draft plan for review Management review and problem solving Day 2 Agenda: Based on the management meeting outcome on day 1, any changes required are discussed. Teams breakout to make any modifications in the scope and replan. Teams bring the PI objectives to the program board.  Business owners assign business value against the PI objective(s).  Final plan is reviewed. Program risks and dependencies are updated in the program board. Teams discuss and decide on the ROAM (Resolved, Owned, Accepted and Mitigated) to see if they can overcome the risk. Confidence vote is taken with respect to the overall planning and commitment. Retrospective is held with respect to the entire PI planning event and any improvement items is taken up for the next PI planning event. This is facilitated and owned by Release Train Engineer (RTE).  Principles of Program Increment Why, What and How? Requirements are rather discovered with the entire Agile Release Train(s) or ARTs that includes the development teams, Product Owners and other stakeholders collaborating on “why” the product/solution is being built. The teams get to know the customer needs better and decide on “what” needs to be built by prioritization. Cross teams within an ART and cross ART dependencies are discussed. Architectural runway - which is the existing code, components and technical infrastructure needed to implement the near-term features without excessive redesign – paves the way for the ART development teams to discuss alternatives, risks and any unknowns to create a view of “How” the increment will be addressed. There are multiple time-boxed activities within this two-day event that allow the teams in the ART(s) to breakout and have a focussed interaction. This approach fosters focus on just enough detail and allows the “spacing effect” and time for reflection The central principle of release planning is the capacity constraint. We will discuss this in the next section. Knowing your capacity constraints during Program Increment Planning Creating a stable and high performing Agile team within an ART depends on how well the team or ART self-manages the capacity constraint. The reason I say self-manage is because this no longer involves resource levelling or critical path techniques that any seasoned project manager would apply. In Scaled Agile, it is just not about the team capacity, it is about the capacity of the Agile Release Train(s). At the team level, one way to determine the capacity to allocate stories in the sprint is by calculating the velocity – that is how many story points can a team deliver during an iteration. Simple way to calculate velocity is to take an average of the story points that were accepted in the previous 6 to 10 iterations/sprints. The capacity is arrived based on the following: Normalizing Story Point estimation across the Agile Release Train In standard Scrum, each team’s velocity is independent of other teams. It is of no concern when one agile team has a velocity of 100 SP per iteration and another agile team has a velocity of 30 SP per iteration. However, in Scaled Agile Framework, when entire Agile Release Train(s) are involved in planning for the PI duration, it is important that the normalized story point estimation is use. Feature capacity Component capacity Other BAU activities the team may need to perform Focus Factor Need to consider focus factor for anything that cannot be planned like any unplanned time loss keeping in mind the daily time off, adhoc unplanned meetings, other official activities, training, Discussion with SME etc Holidays/vacation etc Situation with example  How do we apply normalized story points for Agile Release Trains? Here is an example. Assume a two-week sprint has 10 days. For every full-time person on the team allocate 8 Story Points. (Adjust for part-time). Exclude the Product Owner and Scrum Master. The 8 points is derived from 1 point per day, for 10 days in a 2-week sprint, at 80% capacity Subtract one point for every team member vacation day, public holiday, training day etc. Find a small story and give 1 story point to it. Estimate every other story relative to that one. In a similar fashion, all agile teams in the train estimate the size of work.  Situation: The product management team of an ecommerce division has prioritized a list of Features/Capabilities that are potential candidates for the upcoming PI. Let us assume that the deliverables are not just the features, but there are some components as well that need to be developed to support those features.  The following table represents the capacity constraints for the features/components with the WSJF prioritization FeatureFront EndM/W ComponentB/E ComponentWSJFFeature 170201019.0Feature 26010012.0Feature 3751556.8Feature 46501015Feature 5900511.5Feature 61201008Feature 7190057Arch 10252510Assuming the Agile Release Train(s) capacity is 500 Story Points(where the focus factor, holidays, BAU activities are considered), let us look at what the ART can deliver for the PI based on the above table: Total capacity for ART = 500 SP Based on the above table considering the WSJF, the ART(s) can consider the following to be taken up for the PI. Feature 1 = 100 SP Feature 4 = 75 SP Feature 2 = 70 SP Feature 5 = 95 SP Arch 1 = 50 SP Feature 6 = 120 SP ConclusionAgile Release Train(s) always find it challenging when it comes to commitment based on the capacity constraints during every Program Increment, especially if the train(s) are involved in planning for the first time. However, irrespective of whether teams in the Agile Release Train(s) are composed of feature or component teams, if the capacity constraints are carefully evaluated and on loading the iterations accordingly as mentioned in this article, the teams can be confident of committing to the product management team on what work will be completed during the Program Increment.

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…. >  - 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  ConclusionTransformation 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. 
10773
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. 
8794
Waterfall Vs Agile – Must Know Differences

In this article, my focus is to the bring out the ... 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)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. SummaryThere 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.
6487
Why Do We Use Fibonacci Series for Estimation

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