Search

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  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. 

User Stories and User Stories Examples

10K
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 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 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 whethe 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 Stories
INVEST in User Stories

This 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. 

IDEPICS
E1As a Sales Professional, I want to generate reports so that I can take a decision on the marketing strategy for the upcoming quarter
E2As a Banking Customer, I want to access net banking, so that I can access my account and make transactions
E3As an Administrator of the software, I want to access master records so that I can make changes to customer data


IDFeatures
E2F1As a Banking Customer, I want to access Savings account so that I can view/make transactions
E2F2As a Banking Customer, I want to access Credit Card page, so that I can view and make transactions
E2F3As a Banking Customer, I want to access Loans page so that I can view my loans
E2F4As a Banking Customer, I want to transfer funds, so that I can move my funds to different accounts within my bank and other banks


IDUser Stories
E2F1U1As a Banking Customer, I want to access/view summary of my savings account, so that I know my balance and other details
E2F2U1As a Banking Customer, I want to Login to Net banking so that I can view credit card details
E2F4U1As a Banking Customer, I want to transfer funds within my own accounts so that I can move some balance across my accounts
E2F4U2As 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 banks
E2F4U3As a Banking Customer, I want to add beneficiary to my account, so that I can transfer funds to the beneficiary

Technical Stories
E2TU1As 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 applicationI 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. 

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. 

Join the Discussion

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

1 comments

Umadevi 10 Feb 2021

It’s good user stories . Thank you so much

Suggested Blogs

Best Practices of Scaled Agile Framework - Agile Management

The enterprises have many different frameworks and methodologies to choose from once they decide to adopt the ‘Agile’ approach for project/product development. Designed by the Scaled Agile Inc, the Scaled Agile Framework (SAFe®) is an Agile software-development framework. Earlier, the Agile development methodologies were used on a trial basis for various projects at an enterprise level. The development team experimented in making an efficient Agile method suitable to work in their environment. This resulted in evaluation of methods that worked and that didn’t, which ultimately led to the development of various frameworks and strategies for the adoption of the Scaled Agile Framework. Within the last few years, the Scaled Agile adoption has become popular amongst many enterprises. The two most important responsibilities of management are measuring improvement and ROI. The management needs to choose a solution that best equips with their business model and speed up the delivery and release phases. With these benefits coming handy, more and more professionals are practising lean and Agile methods and implementing it in the enterprises. The Scaled Agile Framework is a highly structured and is mainly used in larger enterprises and is primarily used to for agile development. It is an increasingly popular framework that has been successfully implements in enterprises. The nine principles of SAFe® include as follows: 1. Taking an economic view 2. Applying systems thinking 3. Assuming variability by preserving options 4. Incremental built with fast and integrated learning cycles 5. Building the foundation of milestones on objective evaluation of working systems 6. Visualising and limiting WIP, managing queue lengths and reducing batch sizes 7. Synchronising with cross-domain planning by applying cadence (timing) 8. Establishing deep-rooted motivation of knowledge workers 9. Decentralising the decision making There are three levels in SAFe®, and they’re as follows: • Team All the SAFe® teams are the Agile teams consisting of 5–9 people working in 2-week scrums. They have skills to define, develop, test, and deliver value using XP (Extreme Programming) methods. Unlike the traditional development scrums, they work in collaboration. • Program At Program level, 5–10 SAFe® teams consisting of 50–125 persons create an “Agile Train Release” comprising of stakeholders and development teams. They put in sync their iteration boundaries and facilitate delivery of integrated working systems every 2 weeks. The SAFe®defines the Agile Release Train (ART), which in every 10 weeks (5 iterations) delivers a Potentially Shippable Increment (PSI). The PSIs provides a steady cadence (timing) for the development cycle. • Portfolio The lean–Agile budgeting mechanisms are budgeted by a portfolio, which is a collection of value streams. The portfolio management requires program management, investment funding, strategy, and governance. A portfolio is associated with the enterprise strategy in terms of strategic themes. Epics that define large-development initiatives are captured and analysed by a portfolio Kanban system. There are business epics that are customer facing, and then there are architectural epics that are technology solutions. How the practices of the Scaled Agile Framework benefit the organisation? SAFe® is considered as a framework based on Agile Development, Lean, and Systems Thinking, which has gained worldwide recognition throughout the large corporations and enterprises. Following are the benefits of adopting the Scaled Agile Framework for your organisation: 1. SAFe® allows implementation large team programs and portfolios Initially, the organisations adopt Agile approach and experiment it by its implementation with small teams. After gaining moderate success with small teams, often the organisations would try to increase the size by aligning various teams, programs, and various departments in an organisation to promote collaboration and efficiency in development and shipment of the product. By identifying the key Agile functionalities, Lean and Systems Thinking that scale well, SAFe® addresses all these issues. 2. SAFe® outlines a consistent approach for planning, execution, and delivery of value It becomes difficult for large organisations when numerous Agile teams are involved, because the teams might operate on different cadences (timing), or might use various Agile frameworks, or might rely on varying tools for managing the Agile lifecycle, or the teams might have adopted different technique practices. SAFe® makes use of ART (Agile Release Train), which collaborates various Agile teams on a consistent cadence for every 8–10 weeks. It is known as a Program Increment (PI). This enables the teams of the organisations get together and uncover, plan, and address dependencies of the teams and the risks that might arise. All the teams of ART make use of best practices such as the Scrum-of-Scrums during each PI. At the end of every Project Increment, the ART does the analysis of what was done in the past 8–12 weeks. 3. SAFe® addresses roles and responsibilities across Team, Program, and Portfolio levels Adopting and implementing Agile causes a drastic change across the organisation, which can raise questions regarding the current and new functions. SAFe® addresses all these questions across the various levels. 4. SAFe® provides a framework to bring consistency in strategy and alignment to the program and team levels In an organisation, maintaining an overall alignment with the vision and strategy is often a challenge faced by enterprise-scale software development. It becomes difficult to arrange various business departments with similar strategies, and if that is achieved, the problem still persists to communicate that strategy at the team level. SAFe® provides an architecture to implement Agile, Lean, and Systems Thinking consistently to various levels in an organisation. 5. SAFe® improves product development lead times SAFe® is a well-documented approach that applies its principles, benefits, and values to the wider enterprise. More and more large corporations have understood how to scale Agile to lessen the time required for product development and improve the release time of their product compared to their market competitors. SAFe® provides an extensive set of functionalities that can be applied in an enterprise to successfully scale Agile.
1819
Best Practices of Scaled Agile Framework - Agile M...

The enterprises have many different frameworks and... Read More

Why An Agile Project Management Certification Is The Right Choice?

Professional certification courses for Agile methodologies is available for IT professionals who have worked in Agile projects or who have worked in complex software projects. These certification courses are designed to test your knowledge and competence of the Agile framework. Though there are several Agile-related certification courses available in the market, most of them can be categorized under the umbrella of 2 main categories namely, Project management-based or Scrum-based. This article discusses the details of these 2 categories of Agile certifications and recommends which is the right one to pursue. About Agile Project Management certification The purpose of Agile project management is on developing software solutions incrementally to enable project teams to respond effectively to change in customer requirement, while delivering the product in quicker time to the customer. A certification course in Agile project management is designed to explain the foundation of successful agile projects and on how to manage the project from the start to its completion. An IT professional, certified in Agile project management, has the following benefits: Develops an advanced level of knowledge about Agile and can apply the project management methodology to any software project. Differentiate between the project management principles between traditional and Agile project environments, and apply the same to different work scenarios. Promote a trustful collaboration between the business owners and the Agile development teams, while providing the management day-to-day visibility into the progress of the project. Experienced IT professionals can also combine the learnings of traditional project management methods and Agile methods, thus providing them more control over a fast-evolving business environment. Improve the success rate and time-to-market duration of software releases. Agile project management certifications, such as the Agile Certified Practitioner (ACP) course from the Project Management Institute (PMI) require students who have real-world experience of being part of an Agile project team and provides the students working knowledge of multiple Agile methodologies including Scrum, Kanban, Lean, and others. Additionally, certified ACP holders must earn 30 professional development units every 3 years to maintain their status. About Scrum-based certification While project management-based certification provides a single certification credential, Scrum-based certification is divided into multiple certification courses based on the role being played by the individual in the Agile project. Scrum-based certification offers courses for the following roles: Certified ScrumMaster Certified Scrum Product Owner Certified Scrum Developer Certified Scrum Professional Scrum-based certification program, such as the Scrum Alliance, is designed for software professionals, who can support the adoption of Scrum framework and its benefits in software development. Scrum-based certification is important for individuals from the software industry, who want to grow in an iterative software development environment. Certified knowledge of the Agile methodology can boost their career prospects. Which certification program is better? Gaining certification accreditation for both project management and Scrum can be beneficial for software experts, who want to manage projects for different types of software companies and can benefit from the different project management frameworks. Knowledge of multiple PM frameworks like Scrum, Lean, and XP can only be gained by pursuing both categories of courses. Besides this, let us look at a comparison of these Agile certification courses in the following parameters: Industry orientation A PM-certified individual is oriented towards being both industry agnostic and product agnostic, meaning their specialization is not restricted to any particular industry, or products that can functions on multiple platforms (example, mobile phone and desktop). The Scrum-certified individual, who typically was focussed on software development, is now product agnostic. Job preference The PM-certified individuals are looking at a career as a project manager, as many software industry recruiters demand Agile certification in project manager openings. A Scrum-certified individual is seeking growth and opportunities in the field of software development or to be a Scrum expert in any Agile software project environment. Recertification requirements Individuals certified in Agile PM programs, require to take a recertification (or continued education) on a 3-year cycle. Individuals certified in Scrum-based programs, require to take a recertification (or continued education) on a 2-year cycle. Eligibility Project managers or any team members, who hold any Project manager professional certificate, can benefit the most from the Agile PM certification program. Software team members, who have working knowledge of the Scrum methodology and have been part of Scrum-based projects, can benefit the most from the Scrum certification programs. Conclusion Depending upon the student’s previous experience and future growth map, either (or even both) of these Agile-based certification courses can be pursued for gaining recognition in a rapidly-evolving software development environment.
6710
Why An Agile Project Management Certification Is T...

Professional certification courses for Agile metho... Read More

How SAFe® Became Pioneer In The World Of Framework?

SAFe® principles and practices aim to provide guidance on successfully leading agile projects. It is the approach that helps scale agile to the highest level being the enterprise level. Leading SAFe® is a known Certification that teaches concepts on agile and value delivery through scaled agile framework. It provides insights on lean mindset and approaches to deliver agile release trains. Why companies choose SAFe®, now this is the trending topic in agile members. One of its key focus is also on how to develop and implement agile approaches organisation wide and align team goals to enterprise goals. A major contributor to the wide adoption of Scale Agile Framework Certification and Training is that most of the success on agile so far is based on scrum. While scrum works effectively for small and medium sized organisations where it is relatively easier to manage teams. A greater challenge is posed by large enterprises. These organisations usually have bigger teams and varying team cultures. SAFe® training helps in articulating the ways and approaches that support scaling agile. Multi team and multi project queries are a part of the scaled agile framework Certification giving a methodology that helps guide on how to manage the flow of value from the strategic ideation to actual release in the product. SAFe® brings three critical levels to align their processes and goal guidelines so that they ultimately support scaling agile. These levels are portfolio level, programming level and finally team level. While portfolio level focuses on the strategic decisions, it is the program level team that handles estimations and analysis to decide user story deployment approach. Team level is responsible for the development, testing, and deployment of agile trains in line with all the strategic and operational inputs that flow from above levels. Lean Thinking also plays a critical role in successful Agile Implementations. This mindset is the core of SAFe® Certification. The main goal of introducing lean mindset is to encourage delivery of value to the end user with utilisation of shortest lead time. All key variables of bandwidth, time and effort are organised to ultimately support the goal of giving results within a shorter timeline. Amongst the pillars supporting the concept of SAFe®, a key ideal is respect within the team. Despite the fact that every organisation big or small carriers its own culture, a primary focus on respect enables team members to be open and discuss challenges. Respect is also important to maintain because in agile individuals are empowered to continually focus on improving their methods to deliver better with the agreement from the team. Value Delivery is another reason for this framework gaining more acceptance. The importance of value delivery is evident as each iteration uses some feedback from previous iterations to further improve the end-product. This way the focus is also on continuous improvement of the product through development helps in better prioritization and managing queue of deliverable pieces. Being holistic is also an advantage that SAFe® framework carries. It helps to give a bird’s eye view of all the complex work that happens in the Development and release process. Attention to alignment with top level Strategic goals of the enterprise gives work greater visibility and Helps focus on continuous improvement with each deployment. SAFe® framework is indeed the complete framework for enterprises that want to move away from the traditional waterfall to agile. Since scaling is the biggest challenge of scrum, SAFe® helps to align all targets to ensure that value delivery reaches end user in the shorter span of time and with lean mindset. Supporting lean also helps teams to be more efficient and diverts focus on strategic and iterative improvements sooner than traditional waterfall approach. Continuous process improvements originating from teams are also encouraged to bring greater efficiencies much sooner in value delivery.
3590
How SAFe® Became Pioneer In The World Of Frame...

SAFe® principles and practices aim to provide gui... Read More