Search

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., https://www.scaledagileframework.com/pi-planning/  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 Conclusion Agile 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.  

SAFe Release Planning- Know Your Capacity Constraints

9K
SAFe Release Planning- Know Your Capacity Constraints

As an Agile Coach in 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., https://www.scaledagileframework.com/pi-planning/  

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 Meeting

PI Planning Meeting

Image Source

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

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

SituationThe product management team of an ecommerce division has prioritized 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 ComponentWSJF
Feature 170201019.0
Feature 26010012.0
Feature 3751556.8
Feature 46501015
Feature 5900511.5
Feature 61201008
Feature 7190057
Arch 10252510

Assuming 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 

Conclusion 

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

 

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 *

SPECIAL OFFER Upto 20% off on all courses
Enrol Now

Trending blog posts

Suggested Blogs

Standups for agile teams

Communication is the key for any team working closely to deliver a solution. The foundation of Agile is based on frequent interactions that provide multiple opportunities for the team to come closer, daily standup being one of them. There may be varied names for daily standup like daily scrum, daily huddle, quick catchups, daily sync-ups, etc. but the purpose remains unchanged. Going back to the non-agile days or to the teams which are not working in an agile fashion, they too, choose a time to interact, to update, or to check on any new advancements, but, the frequency differs. So, what makes daily scrum different from others? What is a Daily standup scrum ceremony? The daily standup is one of the scrum ceremonies prescribed by Scrum, where the team meets daily; same time, same place, to talk about Sprint goals and also check if they're on track or if there's a need to change the course. Daily Scrum helps the team to track the progress, for which they use the Sprint board. The Sprint board is essentially used to talk about the deliverables, the associated timelines and if there's any impediment that is stopping them from moving forward. The daily standup meeting is not a status update meeting; it is a time when the scrum team collectively discusses and takes ownership for a Sprint goal.  The term ‘standup’ is used because it is meant to be short and precise. It is usually done with team members standing up to discuss the work items, though this is not compulsory. The purpose of standing up is to keep the meeting short and to the point. Daily standup, in a way, provides daily planning for the scrum teams to stay focused on the sprint goal. How to conduct a Daily standup To conduct a good daily standup, everyone in the team should be aware of the agenda and come prepared for the discussion. The scrum master initiates the meeting with a quick warm-up topic (hardly lasts for a minute) that sets the tone for the meeting and serves as the ice breaker. It can be anything general; from the weather to appreciation, or any topic that makes the team comfortable.  For the entire meeting, the team remains focused and involved. They can stand near the Sprint board or any visual board where they're tracking the progress. In case of a distributed environment, the team should be using the screen share with the details of the sprint board/taskboard. 'Three questions' - the core of Daily Standup: What I did yesterday? What is my plan for today? Or before we meet again. Are there any impediments? Time-boxing the daily scrum meeting is vital; it should not go beyond 15 minutes. If there's anything the team wants to talk about apart from 'three' questions, it should be done once the daily scrum is over. Any discussion on the impediment that doesn't require the complete team should be taken as a sidebar.  Everyone in the team gets a chance to talk about the task/work in hand. As a rule, when a team member is providing the inputs, the other members will listen and stay quiet. This ensures that only one person is talking at a time. The scrum master can introduce creative ways of conducting a daily scrum that helps team participation and induces respect for others.  Here’s an example of how team members can respond to the three questions: “Yesterday, I completed writing the test cases for the login screen.” “Today, I will work with John to get it peer-reviewed and will also start testing the authentication part” “No blockers” Swift and short. Sticking to three questions helps in completing the daily scrum on time. Staying with the rules promotes discipline and better work culture.Why is the daily standup important? Transparency and planning are vital for effective delivery. Getting teams on the same platform requires collaboration, communication, and teamwork. Daily scrum provides the team with the opportunity to talk about the daily task, communicate any blockers, and discuss if there's any change in the plan. A short 15-minute sync up helps the team stay focused on the goal. The team members can call out if they need any help with the work items, which is another opportunity to take ownership as a team.  Some of the benefits of a daily standup include: Improves communication Helps to identify blockages or impediments An opportunity to inspect and adapt Improves team accord Helps to keep the team focused Increases the level of accountability  Creates a sense of accomplishment while talking about the done tasks Though it has many benefits, it can only be reaped if the daily scrum is done in a way prescribed in the Scrum Guide. Daily scrum is one among the five key events to be conducted in a sprint and serves a tactful purpose. For most of the teams, daily scrum is one of the first things that happens at the start of the day. It sets the tone and the expectation for the entire day, similar to creating a to-do list before the start of any work.  Who Attends a Stand-up? The daily scrum is one of the scrum ceremonies that is attended by the development team, the scrum master, and the product owner. Anyone else apart from these three roles can join but they'll have to be quiet and stay as an observer till the time meeting gets over. At times people from different areas who are directly/indirectly involved in the delivery may want to check on the progress. They can be a part of the daily scrum, but the rule applies to them as well, which is, only the scrum team will talk. They can ask questions only when the daily scrum is over. What do we talk about? The format of the daily scrum sticks to the three questions: What I accomplished yesterday? What is the plan for today? Are there any impediments in the path of my work? These three questions help the team to stay focused and timeboxed.  With the first question, the team member will talk about what they have completed before the start of the daily scrum. It consists of the task that they had planned and called out in the last daily scrum. Sometimes there might be a certain deviation from what they had mentioned and what exactly they worked on. This should be called out specifically as part of the daily scrum. Talking about the ‘done’ work creates a sense of accomplishment and sets the right tone for starting up with another task. The second question is more about the plan for today or the plan once the daily scrum is over. Here the team member talks about the work items they plan to finish before the next meeting. It is advised to pull only as per the capacity. While answering this question, there might be a need to change the course of action in case there's a dependency or if there's any impediment that blocks the way forward for that task. When the team member is calling out the items they have planned to work on, it creates a sense of ownership as they announce the strategy. The third question focuses on clearing the path and removing any impediments that might come in the way of delivery. The team member raises any impediment or blockages they foresee, or they talk about the blockers that can impact sprint goal. Talking about the impediments helps the team to readjust the course and look for ways to resolve the blocker as early as possible. Identifying blockers early helps to reduce the risk.  Where and when? The daily standup should happen at the same time and same place. Finding a new place every day creates an overhead and it is time-consuming, hence the reason for ‘same place’. The scrum team should use the sprint board to call out the task and the subsequent progress. Ideally, the daily scrum should happen near the Sprint board. This helps in visualizing the flow and to realize where the team stands in terms of the Sprint goal. Setting up the sprint meeting at the same place daily helps in wiring the minds of the team member to follow the same discipline. If the team is sitting alongside several other teams, it might create a noisy environment to run the daily scrum. In such instances, the scrum master or any of the team members can book a meeting room on a recurring basis.  To address the ‘when’ part, the meeting should ideally be the first thing to be done when work starts. Being the first team activity, it helps in planning the entire day which further creates momentum amongst the team members. The start time must remain consistent and one should avoid rescheduling the daily scrum. With flexible work environments, it might not be possible that everyone is present at the same time during the start of the day. In such cases the team should opt for a slot where they can have maximum participation. Working across time zones requires a slot that works for all. The daily standup should not be treated as a kickoff for the day, but as a time to talk about the advancement towards the goal and the issues and any help required with them. Keeping the meetings timeboxed and on time helps the team to create a disciplined work environment. Daily scrum gives an opportunity to self-organize and work as a team towards a single goal. Stand-ups for distributed teamsWith the worldwide pandemic situation and the teams working from home, we are living in a world with an extremely distributed environment. Agile helps here too. In such cases, the teams should be leveraging the online tools available, such as Zoom, Microsoft Teams, etc. for video conferencing. The calendars should be updated with the recurring meeting invites that consist of a link to join the video.  Why focus on video? Because humans feel more connected through video calls rather than just audio. Also, video conferencing promotes collaboration and creates a sense of a safe environment. Common Downsides to look for: Impediments are not getting raised – There can be multiple reasons for blockers not being shared across the team. Trust issues can be one of them. The Scrum Master/facilitator should help the team feel safe and provide the team with a platform to voice out the issues. Team Members reluctant to join – In some cases, the team members might feel the daily scrum to be a useless activity or it's just another meeting. In such cases, the facilitator should try to understand the reason behind such behavior and coach the individuals on the benefits. Daily Scrum gets converted to the status meeting – There are subtle signals to watch out for. Timebox not being followed. Conclusion If you want the Scrum implementation to work for your team, following the prescribed practices and ceremonies helps a great deal. Even more than the process or ceremony, it is important to understand the team and how to make them energized to start the day, you should also learn how to best leverage the scrum ceremonies to get the best benefits and improve the overall productivity and teamwork. Daily standups help to focus on the common goal and raise the overall morale of the team and project.  
9253
Standups for agile teams

Communication is the key for any team working clos... Read More

Learn Scrum with JIRA

Many organizations use JIRA as a one-shot solution to automate their processes, and JIRA has almost become synonymous with Agile. Even organizations that don’t deploy it across all levels use it for at least some of their projects. Such is the popularity of JIRA. So, what exactly makes it so popular? JIRA provides a simple and easy-to-use solution for project management tasks, right from gathering requirements to maintaining releases and generating all sorts of reports and metrics. The best part of the tool is that it is highly customizable, attending to the needs of one and all. If it is said that there isn’t a thing that one cannot do using JIRA in terms of project management, then that is not an understatement.  Since Agile is the buzzword now and most organizations are opting for it, this article will provide users with a detailed insight on how to carry out their project management tasks and software development activities by using a Scrum framework.   Before moving ahead, there are two basic pre-requisites that the user who intends to use JIRA must have and they are: Pre-Requisites:  An active account on JIRA Required permissions (Super Admin, Project Admin, etc. – Defined by organizations) 1. Creation of Project: The first and most important thing is to create a project in JIRA under which we will be carrying out our activities and tracking the progress of those. There are two ways a user can create a project.  Method 1:  Step 1: Log in to JIRA using your credentials. Once you are logged in, you will land on the project dashboard which will look something like this.  Step 2: Click on Settings icon and select the Projects option as highlighted in the image below.   Step 3: Select “Create Project” option as shown in the image.   Step 4: After clicking on “Create Project”, you will be prompted with two options to select from.  Classic Project  Next Gen Project Step 5: Once you have selected the type of project, you will be asked to enter the Project name. You will also have the option to change the type of template i.e Scrum, Kanban or Bug Fixing, depending on the purpose for which you wish to use JIRA.  Once done, you must click on the “Create” button.  And voila, it’s that simple. Once you have clicked on the create button, you will land on the project dashboard with the name of the project highlighted on the top left. As we can see in the image below, project name “My Scrum Project” is visible. Method 2.  The steps remain the same, only difference is that instead of navigating through settings, once you have logged in, you will have the option to navigate via “Projects” link as depicted in the pic.  2. Creating Backlog: Once the project has been created the second important step is to define requirements in a backlog. As you can see in the pic below, there is the option to select “Backlog” from the left side panel/navigation pane to navigate to the backlog section.  Here you can start creating backlog items. This backlog serves as the “Product Backlog”. Users can outline requirements in terms of Epics, User Stories, Tasks and Bugs which are known as “issue types” in JIRA. In short, everything that is created is an issue in JIRA. Please note that for ease of understanding and reference, I am sticking to the most basic issue types as mentioned above.  Step 1: To create issues in JIRA, all that is needed to be done is to click on the “Create” button on the top most navigation bar. This bar remains visible at all times by default, no matter whichever page you navigate to. Step 2: Once the user clicks on “Create”, a dialog box to enter details of the issue will open.   The two most important fields in this are:  Project: This field, by default, is populated with the name of the project you are in. But in case you wish to change the project field, the same can be selected from the dropdownIssue Type: This option by default is selected as “Story” but can be changed depending on which issue you want to create. The relevant issue can be chosen from the dropdown. Below image shows how it all looks like in JIRA. There are two types of fields on the dialog box; Mandatory and Non-Mandatory. Mandatory fields are marked with a red Asterix. Also, these fields change on change of the issue type i.e. on basis of what is applicable to the issue type being selected.  As already mentioned, JIRA is highly customizable and a JIRA admin can add or change more issue types based on what terminology is being used by the project and/or organization on the whole. E.g. Issue type of Features can also be added in case teams follow a feature-based development approach wherein features are divided across teams and encompass the hierarchy of epics and stories.  In a similar manner, issue type “Story” can be amended to be displayed as “User Story” or at times to be more specific, something like “Functional User story” and/or “Technical User story”. In addition to this, the fields are also customizable. New fields can be added and the rule of mandatory and option field can also be altered depending on what works best for the team. To make these changes, the JIRA admin needs to navigate to the settings section and then to the desired settings type to change them. Please note that these settings will only be available to the user who either is a JIRA admin or has permission to perform these activities. Permissions are issued by the JIRA admin to the user.  Coming back to the topic of creation of backlog, once you fill up the details and click on “Create” at the bottom of the dialog box, a new issue is created in JIRA that now starts reflecting in the backlog.  Issues can also be created by using the short cut link available in the backlog section as highlighted below.  Once you click on “+” icon, you will be able to select the type of issue to create and provide a summary for the same.   After entering the summary details, you are required to click enter and the issue is created. To enter other details, you will have to navigate to the created issue by clicking on it in backlog or opening the same in a new tab and then doing the needful.  As soon as an issue is created, the same starts reflecting in the backlog. Here you can see two stories and one bug that were created, are visible in the backlog. 1. Linking Issues:  We all know the hierarchy of requirements goes something like Epics > Stories > Tasks. JIRA gives us the capability to link one issue type with another. To start with as a very basic ask, stories will fall under the epics and thus need to be linked with the correct epic. This linkage is something which replaces the requirement traceability of traditional models. When everything is perfectly linked then it can be easily known which requirement from the customer was covered under which epic and if we go into a granular level, under which story and even tasks the requirements fall under. Similarly, if a bug is found in the story while working on it, the bug can also be logged and linked against the story.  To link issues, the steps below can be performed.  Epic Link: To link stories under an epic, JIRA specifically provides the field “Epic Link” in stories. The field at most times is made mandatory by organizations to make sure that every story that is created in JIRA is by default linked to the epics. Here the epic becomes the parent issue of the story and thus it also becomes easy to make sure that every requirement has been worked upon.  Step 1: There are two ways to create the Epic link. While creation of the story, you will have the option to mention Epic link or if the story is created using shortcut link, the same can be added by opening the story and then mentioning the epic in the epic link field as shown below. Step 2: Once selected the same starts reflecting in the story details.   Step 3: To see the linkage, you need to navigate back to backlog. The link starts displaying in the backlog.   2. Linking Bugs:  Once the bugs are created, they can be used to block user stories in a similar fashion, though there is no specific field like epic link in case of bugs, they can be linked using the “Link issue” option.  Step 1: Once the bug is created, note the issue ID and open the story which needs to be blocked and select the “Link Issue” option.  Step 2: By default, “is blocked by” option is selected, indicating that the story is blocked due to the following issue. As soon as you enter the bug issue id and click on link, the story is linked with the bug or to be more specific, the story is marked ‘blocked’ by the bug. In this way multiple stories can be blocked with a single bug and vice versa.   Note – Stories can be linked to other stories to showcase linkage, to mark dependency, to display duplicity/redundancy etc in the same manner, all that is needed is to select the correct option from the dropdown after selecting “Link issue”. Issue Prioritization in Backlog.  As the rule goes, the product backlog must be prioritized at all times i.e. the issue with the highest priority should be at the top and the issue with least priority should be at the bottom of the backlog, so that the teams working on the backlog have a clear idea about the work they need to pull in once the next iteration starts or to understand if they have capacity for more during the ongoing sprint. Keeping the backlog prioritized also helps the team to keep working as per the product roadmap in the absence of the product owner and as such the team does not get blocked.  JIRA also provides the capability to keep the backlog prioritized at all times by the simple function of dragging and dropping the issue above or below the other ones. Below images will give you an idea of the same.  Scenario 1: Once you start creating issues in the backlog, the issues start reflecting in the ascending order of their Issue IDs i.e. the order in which they are created. For ease of reference, the issues have been named as 1, 2, 3, 4 and placed one after the other.  Now assume that the priority of Story 4 is the highest and thus it should be at the top of the backlog, followed by test story 2, followed by 1 and 3 respectively. Thus, they should be placed in order of 4,2,1 and 3 in the backlog. This can be done by simply dragging the items to bring them in the desired order.  Scenario 2: Below image gives you a backlog which is sorted on the basis of prioritization of stories as per the priority defined by the PO. Bugs too can be dragged and placed at the relevant position in the backlog depending on their severity and priority. All these activities of creation and prioritization of backlog are done primarily by the PO. In case the PO is supporting multiple teams and there are BAs supporting individual teams or acting as proxy POs for the teams, then POs can leverage them for backlog management. Scrum master needs to ensure that the backlog is prioritized, properly detailed and at least the stories for the immediate next sprint remain in a ready state.   3. Creating & Starting a Sprint:  Once the backlog has been created, the next step for the team is to gather and hold the sprint planning event. PO can open the stories and discuss the details and Acceptance Criteria with team members. Once all the stories have been discussed, the team can start pulling the stories in the sprint and for that to happen the team will need a sprint in JIRA. It is again very simple.  Step 1: In the backlog section, there is a “Create Sprint” button.  Step 2: Once you click on the button; a sprint is created, starting from sprint 1 with a prefix of project ID as shown in the image below. You have the option to create issues directly in the sprint using the quick link as mentioned above for the backlog or the issues can be dragged and dropped in the sprint created. All the issues dragged and dropped in the sprint created, as discussed in sprint planning, will serve as the sprint backlog.  Step 3:  Once all the issues are dragged and dropped in the sprint, the sprint is ready to be started. As an example, we see that test story 4 and 2 as well as a bug have been dragged to sprint 1 as displayed in the image below.Please note as part of sprint planning session, details like Story Assignee, story points and hourly estimates can be filled in the stories using the fields available. Also, in case the story owner wants to highlight the individual tasks they intend to perform as part of working on the story like Analysis, Coding, Review etc or in case multiple team members are working on a single story then to highlight individual work assignments, the option of creating tasks can be used. Tasks can be created just like stories, as mentioned above. It is similar to work breakdown in traditional models.What needs to be made sure is that before marking the sprint planning as being complete, all the stories have been pulled in sprint and assigned and estimated in terms of story points or hours or both, according to the approach the teams have decided to take. All the sub tasks that have been created, can optionally be assigned. If desired, these subtasks can also be estimated. Once all this is done, the Scrum Master can then mark sprint planning as complete and proceed to start the sprint.  As we know that before sprint planning, a goal is provided by the PO to the team. The same goal can be added in the sprint. Just select the three dots option besides the sprint on right side and select edit sprint and you will be able to enter the sprint goal.  4. Starting Sprint: Once the planning is complete and activities like estimations, assignments and tasking have been done, it is time to start the sprint. This is simple to do. In the backlog, there is a “Start Sprint” button. Once you click on it, a dialog box appears where you can verify sprint goal and set a duration for the sprint. After reviewing the details, you can click on “Start” and we are good to go.  5. in Progress:  Once the sprint has started, you can navigate to the “Active Sprint” section to visualize the progress on the stories in the sprint. Team members can update the stories to depict statuses from “To Do”, “In Progress” and “Done” and also update their daily hours in the stories in case teams are estimating in terms of hours.  6. Completing/Closing Sprint:  On the last day of the sprint, it is important to mark the ongoing sprint as closed in JIRA so that next sprint can be planned and started.  All the items which are marked done are considered complete. Anything pending to be completed is either moved to the next sprint or to backlog in consultation with the PO.  Step 1: In the “Active Sprint” section. On the top right corner, you need to click on “Complete Sprint” button.  Step 2: Once the “Complete Sprint” button is clicked, a dialog box appears with details of issues that have been completed and the ones which are pending. Select the place where you wish to move the pending items to, either to the backlog or next sprint which is to be started.Step 3: Once you select the desired value under “Move to” field and click on “Complete” button the Sprint is marked as complete.   
5921
Learn Scrum with JIRA

Many organizations use JIRA as a one-shot solution... Read More

Top 5 Agile Trends to Take You Safe Through 2021 and Beyond

In recent times, Agile has proved to be more than just a buzzword in the IT industry.The amazing results of Agile project management have widened its scope for implementation in other than IT industry also; therefore, we often come across the terms like “being Agile” and “doing Agile”.More and more organizations and enterprises irrespective of size and business niche are adopting Agile with an eye on commitment, delivery values, profitability, customer’s satisfaction etc. Because of continuous Agile evolvement, you need to align Agile practices with the latest trends to compete with excellence in 2018 and beyond. Following are the top five Agile trends that will help you plan and sail safe through the competitive marketing environment.1) Short-Term Activities Oriented Agile Training:Organizing the short-term activities oriented intensive workshop/training, planned to train the participants for implementation of specific skill in real projects, is a new emerging trend in Agile organizations. The long and exhaustive classroom training of 4 or 5 days are no longer a preference. The short–term Agile workshops/training leave the Agile team members with new ideas and cohesive understanding of the Agile roadmap. The improved capability to execute short iterations supports to market the product early. In addition, Agile workshops are helping the organizations to develop multi-disciplinary Agile specialists to maximize overall performance.2) Rapid Feedback:Predictions are good to plan but the ever-changing working conditions, new demands, and altered quality standards etc deviate the results. The biggest trend in Agile management for 2018, I noticed recently, is to focus more on rapid feedbacks of developments rather than depending on the predicted outcome. Rapid feedback is vital for Agile teams to understand the way project development is going. Creating a friendly environment allowing every team member to comment and even seek the feedback saves considerable time besides giving a true picture of progress. Continuous Integration (CI) is the best tool to maximize the benefits of rapid feedback.3. Embracing Agile Spirit:  Over the years, a number of organizations twisted & curled Agile methodology to meet their interests and suitability; as a result, some of these tasted just the semi-success. The new trend shows that organizations are embracing the Agile spirit as a part of organizational culture. Organizations are conducting short-period objective oriented trainings to strengthen the Agile mindset of team members.The application of modern Agile principles leads the organizations to deliver more values with satisfactory profit. There are four core characteristics of Agile mindset - value matters, small cycles matters, ecosystem in entire organization matters and culture matters. Agile Spirit embracement can be improved by following the five simple tactics- be transparent, be disciplined, ensure participation, get everyone aligned and set up collaboration as an Agile tool.  4) Cloud-Based Solutions:More Agile teams are adopting cloud-based solutions to find new ways for envision (prediction), coding, testing and deployment faster than they are/were doing now with the intention to have an edge over their competitors. Server-less computing has become the favorite of Agile teams; as, it reduces the need of ‘always on’ traditional server infrastructure, in addition to reducing the infrastructure and operational costing. The organizations that follow cloud-based Agile methodology have enormous competitive advantages supporting for higher quality, greater agility, faster market responsiveness, reducing costing, improving client’s experience etc. It can be said that Cloud technology is going to be an Agile accelerator.5) More Focus on ‘Business Value’ of User Stories:“If you can’t measure the results, you can’t improve the process” fine fits to modern Agile culture. Today, Agile organizations are more focused on measuring the lagging indicators like ROI of new products/ features, Net Promoter Score (NPS) of team members & customers, cycle time and operational stability etc. Using three-dimensional metrics, encompassing complexity, ROI and business value, is the new approach to measure the business value of a user story. Identifying business values before writing a user story rather than writing a user story and then evaluating the business values is a significant shift in modern Agile practice.Summary:Agile culture adoption is growing fast in organizations around the world. Internal Agile coaches, consistent Agile practices, and implementation of a common tool across Agile teams are the top three factors encouraging businesses to continue their Agile journey. According to ‘12th annual State of Agile report’, the top five Agile benefits reported by the organizations are –Better project visibility – through- rapid feedbackFaster delivery – through – cloud-based solutionEnhanced productivity – through – activities oriented learning workshopsImproved ability to manage the changing priorities – through – deep focus on business value of a user storyBetter IT alignment – through – Agile spirit embracementKnowledgeHut provides objective-oriented customized Agile training that helps the organizations match the steps with the latest trends in Agile methodology.
1133
Top 5 Agile Trends to Take You Safe Through 2021 a...

In recent times, Agile has proved to be more than ... Read More