Search

Trending blog posts

Sprint Backlog and the Scrum Sprint

If you are in Scrum, you will hear the word ‘Sprint’ day in and out! You may have heard this word being used in sports by athletes. But if it is something related to sports, then why are we using it in IT?  Well, even scrum has been derived from rugby! So, what exactly is Sprint in our IT industry? The Scrum framework has various components like events, ceremonies, and artifacts, all these components are tied to a timeline called ‘Sprint’. Sprint is a timebox during which the development team creates and delivers the solution to the client.  Sprint defines a period that is focused on brainstoarming, solutions, and delivering a quality product. The timebox or period can differ based on the nature of work and expected delivery. In this article, we will talk about Sprint backlog and the Sprint. Not only will this help you in creating a healthy backlog,but you will also learn about various techniques for estimating and prioritizing your bucket. What is Sprint Backlog and how to create it? The sprint backlog is a list of items that the team commits in a Sprint. It consists of user stories, bugs, enhancements, or any requirement that is related to the product. The sprint backlog is derived from the product backlog hence you can term Sprint backlog as a subset of the Product backlog.  The development teams can use Excel or any agile tool to create their Sprint backlog. With the timebox, known as Sprint, the scrum team utilizes sometime during the first day of the sprint to plan out the roadmap for the entire sprint; usually, this is four hours for a sprint of 10 working days. The team pulls the high priority item from the product backlog, discusses the solution, the risks and the challenges and comes to an agreement together as a team and makes a commitment. They do this activity till the time backlog fills as per the capacity or the intended velocity. When is the Sprint backlog created? The Sprint is initiated with the Sprint planning meeting. This can be seen askick-off for a new timeline. The Scrum team uses the ceremony called “Sprint Planning” to come up with the Sprint Backlog. Usually, the sprint planning meeting goes on for about 4 hours for a two-week sprint with the team size between 7 to 9 members.  The planning ceremony is divided into 2 parts. The first part focuses on building up the backlog, ordering the items as per the priority, and adding an estimate. In the second part, the team takes care of all the details that would be required to complete the Sprint goal. The sprint backlog is one of the outputs from the Sprint planning meeting, it helps the team to stay focused Sprint.Sprint Backlog connection with the sprint ceremoniesAgile talks about planning at every layer, whether it is the strategy, portfolio, product, release, iteration, or daily planning. Let us look at the connection of Sprint backlog with different scrum ceremonies.Sprint PlanningAgile talks about planning at every layer, whether it is the strategy, portfolio, product, release, iteration, or daily planning. Let us look at the connection of Sprint backlog with different scrum ceremonies.Daily standupThe scrum team uses the daily standup to discuss progress on this sprint goal. In this meeting, they talk about the backlog items, what has been done so far, what backlog items the team will pull next and if there are any blockages in their way. Every day the scrum team meets in front of the Sprint backlog. It can be in the form of a tool or a whiteboard with sticky representing different work items and use this Sprint board as the base for the meeting. This not only helps them to stay on track, but it also helps them to foresee any risk, challenge, or an impediment that can hamper the progress of the sprint.Sprint review This is when the Scrum Team showcases their work to the stakeholders. The team gives the demo on the finished items from the sprint backlog. In other words, whatever work was committed in the Sprint backlog gets demoed in the sprint review meeting. Sprint retrospective During the sprint retrospective meeting the team brainstorms on what went well, what did not, and how can they make it better next time. Here we can talk about the best practices that helped them deliver requirements on time with quality.  They can refer to the Sprint backlog to talk about creating better requirements and even better estimations. In my experience, I have seen individuals applauding their team members for good work done on the sprint backlog.    Creation of the Sprint Backlog Who creates or owns a Sprint Backlog? Creating a Sprint backlog is a joint effort from the team, the product owner, and the scrum master. Together, they come up with a plan, discuss the implementation and the ownership lies with the Scrum team. When the Sprint backlog has been created and the team has committed to a Sprint goal, no one except the development team change the sprint backlog.How often should it be updated? What happens if it isn’t updated properly?Keeping the sprint backlog updated is important for the success of this sprint. It not only provides transparency, but it also helps the team in managing their ongoing work. The development team should update the Sprint backlog continuously as and when the work is done, or if they move to a different requirement or story.Many teams update their Sprint backlog during the daily standup meeting. It is advisable to update the sprint backlog at least once per day. In case the team has not been updating the sprint backlog, the burndown chart gets impacted and it will not reflect the correct picture.The team checks and updates the Sprint Backlog during the Sprint, keeping the Sprint Goal intact. They will thus know whether they will be able to finish the Product Backlog items they picked for the Sprint.What does Sprint Backlog contain?Sprint backlog contains the product backlog items which the team has committed to complete in the sprint timeline. It can include tasks, bugs, research items, and at least one process improvement item which is good to have. If the team comes across any new item that is required to attain the Sprint goal, they can add it to their sprint backlog.Estimating and prioritizing the sprint backlog Keeping the backlog healthy is the utmost priority for the team, this requires knowledge of estimation techniques and prioritizing tools. The scrum master can coach the team with an understanding of Effective an efficient prioritization and estimation. Let us look at the ways of prioritizing and estimating the Sprint backlog.Prioritizing the Sprint BacklogSprint backlog is created with the items from the product backlog, which means they are already ordered and are in line with the priority as per the client or the stakeholder. Pulling items into the Sprint backlog does not mean that the priority will change because the sprint backlog is still tagged to the product backlog. Hence, the Sprint Backlog stays ordered as per the priority as it depends on its parent ‘Product Backlog’. The estimate helps the team to limit the amount of work they can commit in the sprint. Also, recognizing tasks and estimating them during sprint planning assists team members to better organize their work. Below are a few of the widely used techniques for estimation:Planning Poker Here, every participant uses a numbered (Fibonacci) card and estimate the stories. Voting is done anonymous and the team discusses when there is a big difference in the estimates provided. Voting is repeated until the complete team reaches a consensus around the precise estimate. It works well when the team must estimate a comparatively small number of stories, a maximum of 8-10, with a small team.T-Shirt Sizing This is a seamless method to estimate a large backlog of relatively large items. Particularly when you have numerous parallel scrum teams occupied on the same product. Items are estimated into t-shirt sizes: XS, S, M, L, XL.The Bucket System More effective than planning poker, this method is a decent substitute when the team must estimate many items with a big group of members. Here, you form several buckets in the arrangement of planning poker. The group evaluates the items by placing them in these “buckets”.  Dot Voting A highly simple and effective technique to estimate. This technique is more of a decision making and one can use it for estimating. Everyone in the group gets a few stickers and can pick to vote for the individual items. The more dots is an indicator of a bigger size. This method works fine with both small and large teams. In Conclusion The Sprint backlog provides structure to the team and helps them stick to the plan by focusing on the sprint goal. Creating a Sprint backlog is a collaborative effort between the scrum team members, this serves as a runway for the iteration and smooth execution of commitment.  To achieve the Sprint goal, it is important to have a healthy sprint backlog. I hope this article helps you create a good Sprint backlog that serves your sprint goal.
Sprint Backlog and the Scrum Sprint
Deepti
Rated 4.0/5 based on 15 customer reviews
Deepti

Deepti Sinha

Blog Author

Deepti is an Agile Coach by profession and Freelance Trainer with over 11 years of industry experience working primarily with healthcare & finance clients in delivering business. She has played a wide variety of roles in the graph of her career, whether it be, management, operations or quality. She likes reading fiction, management and loves to write her experiences. Her colleagues mostly describe her as very detail oriented person with a knack of creativity and imagination. And yes, she loves feedback more than her coffee!!

Posts by Deepti Sinha

Sprint Backlog and the Scrum Sprint

If you are in Scrum, you will hear the word ‘Sprint’ day in and out! You may have heard this word being used in sports by athletes. But if it is something related to sports, then why are we using it in IT?  Well, even scrum has been derived from rugby! So, what exactly is Sprint in our IT industry? The Scrum framework has various components like events, ceremonies, and artifacts, all these components are tied to a timeline called ‘Sprint’. Sprint is a timebox during which the development team creates and delivers the solution to the client.  Sprint defines a period that is focused on brainstoarming, solutions, and delivering a quality product. The timebox or period can differ based on the nature of work and expected delivery. In this article, we will talk about Sprint backlog and the Sprint. Not only will this help you in creating a healthy backlog,but you will also learn about various techniques for estimating and prioritizing your bucket. What is Sprint Backlog and how to create it? The sprint backlog is a list of items that the team commits in a Sprint. It consists of user stories, bugs, enhancements, or any requirement that is related to the product. The sprint backlog is derived from the product backlog hence you can term Sprint backlog as a subset of the Product backlog.  The development teams can use Excel or any agile tool to create their Sprint backlog. With the timebox, known as Sprint, the scrum team utilizes sometime during the first day of the sprint to plan out the roadmap for the entire sprint; usually, this is four hours for a sprint of 10 working days. The team pulls the high priority item from the product backlog, discusses the solution, the risks and the challenges and comes to an agreement together as a team and makes a commitment. They do this activity till the time backlog fills as per the capacity or the intended velocity. When is the Sprint backlog created? The Sprint is initiated with the Sprint planning meeting. This can be seen askick-off for a new timeline. The Scrum team uses the ceremony called “Sprint Planning” to come up with the Sprint Backlog. Usually, the sprint planning meeting goes on for about 4 hours for a two-week sprint with the team size between 7 to 9 members.  The planning ceremony is divided into 2 parts. The first part focuses on building up the backlog, ordering the items as per the priority, and adding an estimate. In the second part, the team takes care of all the details that would be required to complete the Sprint goal. The sprint backlog is one of the outputs from the Sprint planning meeting, it helps the team to stay focused Sprint.Sprint Backlog connection with the sprint ceremoniesAgile talks about planning at every layer, whether it is the strategy, portfolio, product, release, iteration, or daily planning. Let us look at the connection of Sprint backlog with different scrum ceremonies.Sprint PlanningAgile talks about planning at every layer, whether it is the strategy, portfolio, product, release, iteration, or daily planning. Let us look at the connection of Sprint backlog with different scrum ceremonies.Daily standupThe scrum team uses the daily standup to discuss progress on this sprint goal. In this meeting, they talk about the backlog items, what has been done so far, what backlog items the team will pull next and if there are any blockages in their way. Every day the scrum team meets in front of the Sprint backlog. It can be in the form of a tool or a whiteboard with sticky representing different work items and use this Sprint board as the base for the meeting. This not only helps them to stay on track, but it also helps them to foresee any risk, challenge, or an impediment that can hamper the progress of the sprint.Sprint review This is when the Scrum Team showcases their work to the stakeholders. The team gives the demo on the finished items from the sprint backlog. In other words, whatever work was committed in the Sprint backlog gets demoed in the sprint review meeting. Sprint retrospective During the sprint retrospective meeting the team brainstorms on what went well, what did not, and how can they make it better next time. Here we can talk about the best practices that helped them deliver requirements on time with quality.  They can refer to the Sprint backlog to talk about creating better requirements and even better estimations. In my experience, I have seen individuals applauding their team members for good work done on the sprint backlog.    Creation of the Sprint Backlog Who creates or owns a Sprint Backlog? Creating a Sprint backlog is a joint effort from the team, the product owner, and the scrum master. Together, they come up with a plan, discuss the implementation and the ownership lies with the Scrum team. When the Sprint backlog has been created and the team has committed to a Sprint goal, no one except the development team change the sprint backlog.How often should it be updated? What happens if it isn’t updated properly?Keeping the sprint backlog updated is important for the success of this sprint. It not only provides transparency, but it also helps the team in managing their ongoing work. The development team should update the Sprint backlog continuously as and when the work is done, or if they move to a different requirement or story.Many teams update their Sprint backlog during the daily standup meeting. It is advisable to update the sprint backlog at least once per day. In case the team has not been updating the sprint backlog, the burndown chart gets impacted and it will not reflect the correct picture.The team checks and updates the Sprint Backlog during the Sprint, keeping the Sprint Goal intact. They will thus know whether they will be able to finish the Product Backlog items they picked for the Sprint.What does Sprint Backlog contain?Sprint backlog contains the product backlog items which the team has committed to complete in the sprint timeline. It can include tasks, bugs, research items, and at least one process improvement item which is good to have. If the team comes across any new item that is required to attain the Sprint goal, they can add it to their sprint backlog.Estimating and prioritizing the sprint backlog Keeping the backlog healthy is the utmost priority for the team, this requires knowledge of estimation techniques and prioritizing tools. The scrum master can coach the team with an understanding of Effective an efficient prioritization and estimation. Let us look at the ways of prioritizing and estimating the Sprint backlog.Prioritizing the Sprint BacklogSprint backlog is created with the items from the product backlog, which means they are already ordered and are in line with the priority as per the client or the stakeholder. Pulling items into the Sprint backlog does not mean that the priority will change because the sprint backlog is still tagged to the product backlog. Hence, the Sprint Backlog stays ordered as per the priority as it depends on its parent ‘Product Backlog’. The estimate helps the team to limit the amount of work they can commit in the sprint. Also, recognizing tasks and estimating them during sprint planning assists team members to better organize their work. Below are a few of the widely used techniques for estimation:Planning Poker Here, every participant uses a numbered (Fibonacci) card and estimate the stories. Voting is done anonymous and the team discusses when there is a big difference in the estimates provided. Voting is repeated until the complete team reaches a consensus around the precise estimate. It works well when the team must estimate a comparatively small number of stories, a maximum of 8-10, with a small team.T-Shirt Sizing This is a seamless method to estimate a large backlog of relatively large items. Particularly when you have numerous parallel scrum teams occupied on the same product. Items are estimated into t-shirt sizes: XS, S, M, L, XL.The Bucket System More effective than planning poker, this method is a decent substitute when the team must estimate many items with a big group of members. Here, you form several buckets in the arrangement of planning poker. The group evaluates the items by placing them in these “buckets”.  Dot Voting A highly simple and effective technique to estimate. This technique is more of a decision making and one can use it for estimating. Everyone in the group gets a few stickers and can pick to vote for the individual items. The more dots is an indicator of a bigger size. This method works fine with both small and large teams. In Conclusion The Sprint backlog provides structure to the team and helps them stick to the plan by focusing on the sprint goal. Creating a Sprint backlog is a collaborative effort between the scrum team members, this serves as a runway for the iteration and smooth execution of commitment.  To achieve the Sprint goal, it is important to have a healthy sprint backlog. I hope this article helps you create a good Sprint backlog that serves your sprint goal.
Rated 4.0/5 based on 15 customer reviews
Sprint Backlog and the Scrum Sprint
Blogs
6558
Sprint Backlog and the Scrum Sprint

If you are in Scrum, you will hear the word ‘Spr... Read More

The Ultimate Guide to Sprint Planning

The Scrum framework has been popular lately and several studies have provedthat the global share of Scrum is more than 50%. One of the reasons for the phenomenal success of Scrum lies in its ceremonies, one of its key pillars.  Scrum has three critical components that create the structure or a skeleton and provides a way of working to the teams and individual, namely, roles, artifacts, and ceremonies. crum roles, artifacts and ceremoniesScrum has four different ceremonies to support Agile software delivery where the Sprint starts with planning and ends with the retrospective. Let us quickly talk about the four ceremonies and then we will start with our topic of the day and deep dive more into Sprint planning. Daily Scrum The event is intended to bring together everyone in the scrum team and talk about what the accomplished last, what is the plan for today and is there any impediment. This event can be categorized under daily planning and collaborative team effort to attain the scrum goal. Sprint planning This event occurs at the start of the Sprint where the team together decides on the Sprint backlog and gains consensus on the sprint goal. They also talk about the estimation, capacity, risk, dependencies, and the timeline. This event is facilitated by the scrum master and occurs once in every Sprint. Sprint review This is the second last event in the print where the team showcases the entire deliverable they have been working throughout this print. This is the time when the stakeholders look at the finished product and provide their feedback. The event provides an effective platform for a collaborative approach with the client towards software delivery. Sprint retrospective This is one of my favorite events in Scrum, though the ceremony looks simple, if done correctly, it can yield tremendous results. It provides the team with a chance to pause and check which things are working, what is not, and how can they improve moving forward. Scrum ceremoniesEach of the ceremonies can be elaborated more as they are deep and dense. This article serves as an in-depthguide on Sprint planning for Scrum practitioners. The Sprint Planning meeting The What Sprint planning can be thought of as a ‘green flag’ that gives a go-ahead to the train called “Sprint”. The purpose of this meeting is to provide the sprint goal and ‘how’ that can be delivered. This is the first meeting that takes place in a Sprint where the scrum team comes together to create the Sprint backlog within a “time-box”, this time-box depends on the iteration length, if the iteration is of two weeks, the time-box can be up to four hours for a team of seven to nine people.  During the Sprint planning meeting, the product owner describes the objective of the sprint and what product backlog items can be utilized to reach that objective. Consequently, the scrum team decides how to work on ‘how’ to get the goal achieved. The How The sprint planning meeting is divided into two parts, first part, constitutes discussion on the sprint backlog creation and the second part revolves around the capacity and estimation. The product owner must keep the product backlog stays in a healthy state, it is prioritized and has the right requirements for the team to work on. The team should also be aware of their capacity and velocity to make appropriate Sprint commitment. Spring Planning meeting agendaThe Who The spring planning meeting is attended by the product owner, the development team, and the scrum master. All three roles are mandatory to run this meeting.  The product owner defines the objective of the sprint and supports the development team with the product backlog. In turn, the development team talks about ‘how’ to deliver and the approach they could take. They can also inform the product owner if the requirement is not doable (at times, the requirements might not be technologically feasible, in such cases the team can discuss the same with the product owner). The Scrum Master takes up the facilitation of the event, they make sure the team sits with an effective ‘input’ and comes out with an efficient ‘output’. The Inputs The Product Backlog serves as the ‘Input’ for the Sprint Planning meeting. It provides the development team with the starting point as it contains the list of requirements for delivery. The Product Backlog is owned by the product owner and hence the responsibility of keeping it up-to-date falls within their purview. The team starts with the highest priority item in the list, clear doubts (if any) and add it up to the Sprint Backlog. To make proper sprint commitment, the team should know their capacity and velocity. The Outputs The sprint planning meeting intends to generate a sprint goal and backlog. The output also defines the ’how’ approach, which the team will take to reach its goal. The team must understand the value of this event, as this draws a path for sprint success. The Scrum Master can help the team and the product owner to come up with an effective plan through their facilitation skills.Input and output of the Sprint Planning MeetingHow do we prepare for the sprint planning meeting? As with other events, the sprint planning meeting has a set agenda and timebox which the team must follow diligently. A healthy backlog is a key to efficacious sprint planning, which means, the Product Owner always must maintain and keep the backlog updated. The team needs to be aware of the available capacity and the targeted velocity this helps in coming up with the correct commitment during the Sprint planning session. What is a backlog? A backlog is a list of requirements from the client to create the desired product. It contains new features, enhancements, bugs, Infrastructure changes, or any architectural requirement. Any work that is related to a product should be in the backlog.  Backlog items are placed in a prioritized list manner Every item in the backlog has an estimate it can either be a high-level estimate or the exact/close estimate, depending on where it falls in the list. Usually, the top few items in the bucket have more clarity, details, and close estimates as compared to the items down in the list. Determining velocity Velocity is unique for every team; no two teams can have the same velocity. Every organization has a different approach towards velocity, ideally, the teams should take an average of the last five sprints. The average formula works for the teams who have been in the system for long or they have spent at least eight to ten sprints as a team.  Usually, velocity-based planning is done with mature teams who are aware of the product and they are good at process. With new teams, the ideal approach relies on the completed stories vs accepted stories ratio. Determining capacity Capacity is determined by available working hours in the sprint timeline which also takes into consideration, the leaves, any holidays, and contingency hours (if required). Capacity directly impacts the output as a team and helps them during Sprint commitment.  Sprint Planning checklist While Agile development is more of a mindset than a methodology, checklists can help guidetheproduct owner, the development team, and the scrum master as they plan and execute sprints. Sprint planning preparation A few days out from the actual sprint planning meeting: Review product roadmap and vision.  Ask team members to update boards and focus on moving tickets to done.  Run sprint review and retrospective.  Groom product backlog: Make sure every user story has a clear priority, is fully formed, and up to date with context and estimates.  Choose sprint goal.  Create a sprint backlog of enough user stories to fill two sprints. Sprint planning meeting Ensure your entire team is present for the meeting.  Start video call for remote team members.  If needed, clean up old board(s) with team by checking status of open tickets.  Discuss spillovers: Should these be continued or dropped? Move any spill-over tasks into the right buckets.  Set the stage with product and market updates.  Define the sprint goal.  Create a “new sprint”. Discuss the goal and team’s capacity:  Is this realistic? If not, can the team lower the scope?  Worst case scenario the product owner needs to come up with a new sprint goal. A few days out from the actual sprint planning meeting: Discuss proposed sprint backlog: Let the team pick user stories and tasks that match the sprint goal and capacity.  Discuss the definition of “done”.  Break down each user story into individual tasks: Make sure each task has as much information as possible.  Ask whether the scope of work leaves time for unexpected issues.  Ask if the scope of work leaves space to tackle bugs and technical debt.  Move sprint backlog of decided-upon user stories and associated tasks into the sprint board.  Get verbal confirmation from the team that they know what to do.  Set up due dates and times for future scrum meetings.Here is a quick checklist to help you plan the Sprint Plan. You can modify and adapt as necessary.The outcome of the Sprint Planning meeting The planning meeting intends to come up with Sprint goal and sprint commitment which is in the form of Sprint backlog. This backlog contains a list of stories, bugs, enhancements, etc. as required by the product owner. The output of the Sprint planning meeting is also to define the approach, the task, and other activities required to achieve the Sprint goal.  Everything that needs to be done is part of the Sprint backlog, by the end of Sprint planning meeting the team should have a solid plan with the ownership This output is further shared with the stakeholders, management and within the team which not only helps in being transparent but it also supports the team to stay focused. How to get Sprint Planning right Scrum focuses on time boxing and hence Sprint planning also requires control over the time limit for the event. As per the industry standards, a sprint of two weeks should be time-boxed for a maximum of 4 hours. The scrum master is responsible for making sure the team sticks to the timing and helps them in coming up with the plan. Spend planning can be an exhaustive ceremony where the team brainstorms, discusses the requirements and ownership.  With great facilitation skills, the scrum master can ask the team to start with an item they know well and subsequently move forward. The team can utilize various estimation techniques to define a number or a story point for each requirement. They can use T-shirt sizing, poker planning, or any other technique they are comfortable with. For effective estimation, the team needs an environment that is transparent, trustworthy, and open to new ideas. This reminds us of the Scrum values and principles that form the foundation of the framework. Common reasons why Sprint Planning fails Multiple reasons can contribute to scrum planning failure. Let us look at some of the frequent cases: Uncooked backlog Most of the time the product backlog is not up to date and lacks prioritization. In such cases the team struggles in defining the Sprint goal, they face difficulties in defining the Sprint commitment due to lack of clarity and details. Unrealistic expectations Oftentimes teams are required to work on requirements that are not feasible, or the team faces some technological challenge. Over-commitment When the teams do not realize the capacity and their velocity and tend to over-commit, this leads to hurdles in delivery. Beyond Time-box Spending too much time in Sprint planning can also jeopardize the event, the team must follow the time-box, going over minute details is not required. Scrum is an empirical process, which means You do not have to plan everything upfront.   Quick tips for success Set a Goal The Product Owner should come up with a sprint goal and share it with the development team. The goal helps the team and staying focused throughout the sprint, they can also use baby scrum meeting to check if they are on track with the goal. Healthy product backlog If the product backlog is in the Good shape, and has stories in order of priority, the team can start pulling from the top. they can even plan a pre-planning meeting, which is also known as backlog grooming who defines the upcoming sprint backlog. Valuable meeting measures Everyone in the team should have the sprint planning meeting invite and if required it should contain the link to video conferencing in-case of a distributed team. The team should have the data on capacity and velocity, and they understand estimations and prioritization. They can use different colored stickies to represent backlog items for example stories can be represented with green and bugs can be presented with red. As per the discipline, the team should follow timeboxing strictly, they can finish early but to go beyond the time is not recommended.  Best practices in Sprint Planning To course a positive sprint, you need to be very prepared and have a solid understanding of what is practicable to shape with the team you have within the timebox. This is the reason why a sprint planning session is so vital for placing the foundation for an agile development project. Let us touch base on some best practices that the teams can adopt for the smooth running of the scrum event. Strategy for uncertainties During the sprint planning meeting, the team talks about capacity, velocity, and shapes their Sprint commitment around the confident items. Planning for uncertainties not only helps in contingency but it also reduces the upcoming risk that can pose an impediment for the team. Sprint skeleton Laying out the stories or Sprint items in the form of a map helps the team in getting a tentative idea around each deliverable. this also helps in defining the internal dependencies and the teams can better plan by moving them up and down. Building consensus It is important to get the team onboarded together as a single group for the sprint goal. They should understand the importance and the urgency of the deliverable and they are ready to take the ownership, this also requires supporting the teammates. Benefits of Sprint Planning A successful Sprint planning creates a smooth runway for the team to start their work. It provides clarity in terms of commitment, goals, timelines, and ownership. The output of the Sprint planning meeting sets an expectation with both the parties - the scrum team and the stakeholders - on what to expect by the end of the Sprint. It can be visualized as the team pulling a bucket of work from a big pile and focus on delivering that bucket with expected quality. Ready, set, sprint! “A goal without a plan is just a wish.” - French writer and pioneering aviator, Antoine de Saint-Exupéry Done in the right spirit, Sprint planning can do wonders in sprint delivery. All it requires is a focused approach, discipline, few best practices, and a collaborative approach towards a solution.  If you have followed this guide, at the end of your sprint planning session you and your entire team should walk away with: An agreed-upon Sprint Goal and a clear definition of “done” Commitment to a realistic sprint backlog Understanding of the bug fixes and support work included in the backlog Detailed tasks for each user story with an estimation and acceptance criteria Due dates and scheduled scrum meetings Now, all you have to do is the work.Ready to start or grow your Agile career?  Check out our latest courses, learn the skills and get the personalized guidance you need. 
Rated 4.0/5 based on 13 customer reviews
The Ultimate Guide to Sprint Planning
Blogs
6744
The Ultimate Guide to Sprint Planning

The Scrum framework has been popular lately and se... Read More

What is Agile? What is Scrum?

Over the decades, companies across the globe have been adopting different project management frameworks and methodologies they feel are best suited to the nature of work they do. Be it IT, healthcare, fast-moving consumer goods, electronics, or automobile, organizations across domains adopt frameworks that enable them to achieve their organizational goals and best fulfil their customers’ needs.  Much before the birth of the term ‘Agile’, several project management practices like Waterfall, Kanban and XP were being followed. However, there was a wide dissatisfaction with the rigidity of some of these practices. Over the years, academicians and leaders in the industry began to discuss the need for processes that would give them more flexibility and enable them to ship software on time.  After much planning, seventeen innovative industry leaders, many of them from the software community,gathered in February of 2001 at the famous Snowbird Ski Retreat at the Wasatch mountains of Utah, US. This small, three-day retreat ended up shaping much of software is imagined, created, and delivered - and probably even how the world works. What is the Agile Methodology all about? Agile is a mindset, a methodology that provides different frameworks working in an iterative and incremental manner to arrive at a solution.The Agile methodology focuses on creating a red-carpet, a smooth path for teams to work and deliver exceptional results to satisfy customer needs. Over the last two decades, the Agile methodology has dominated the IT industry in a big way. Not only is the Agile methodology customer focused, but it also helps teams to scale up, learn and grow. There was a time when organizations thought about Agile as a fairy-tale wand, something that could magically fix all their problems. Thankfully, with much help fromthe Agile front-liners, the enchanted fairy dust has now evaporated. People now understand that it indeed takes a lot of effort, awareness, coaching, and dedication to fix problems through Agile. Like any other method, Agile too takes time, but if applied in its true sense, the results can be very fulfilling. The Magic Potion: Agile Values and Principles With the coining of the term ‘Agile’, its foundation was laid, the beautiful truth on how to move forward and abide by the rules and values of Agile. At the Snowbird retreat, the seventeen leaders put together a manifesto. The Agile Manifesto is unique among typical manifestos in that it does not declare truths self-evident. Rather, it compares: We value this over that. At Snowbird, the leaders began to lay out what they had in common and when they compared how they did their work, they were amazed at the things that were the same. They went on to finalize the four lines of the manifesto which forms the backbone of all the frameworks that come under the Agile umbrella. Every line has deep meaning associated with it and you will be surprised by its wide-spread relevance across domains. So, what is the Agile manifesto? The preamble reads, “We are uncovering better ways of developing software by doing it and helping others do it.” It then lays out the four core values: The four core values of the Agile ManifestoThe document concludes that “while there is value in the items on the right, we value the items on the left more.” Although the words can be interpreted differently, the basic gist is this: Put people over process. Focus on making software that works, not documents about that software. Work with your client rather than fight over a contract. And along the way, be open to change. With the above four core values, the authors also devised twelve principles that help teams to understand and adopt Agile as their way of working. Even if teams are yet to learn how to use any of the frameworks or how to work around the ceremonies, if they understand and adopt the four values and twelve principles, the battle is won.Here are the twelve principles laid out in the Agile Manifesto:Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. Welcome changing requirements, even late in development. Agile processes harness change. for the customer's competitive advantage. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. Business people and developers must work together daily throughout the project. Build projects around motivated individuals. Give them the environment and support they need and trust them to get the job done. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. Working software is the primary measure of progress. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. Continuous attention to technical excellence and good design enhances agility. Simplicity, the art of maximizing the amount of work not done, is essential. The best architectures, requirements, and designs emerge from self-organizing teams. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. The Twelve Principles of the Agile ManifestoWhat are the various Agile Methodologies? Under the overarching Agile umbrella, many frameworks operate and cater to different industries and market needs. Let us look at some of the most widely used Agile frameworks: ScrumScrum is an incremental and iterative way of working in a time-boxed manner to solve complex adaptive problems. It is a widely used approach as per the 14th Annual Report by VersionOne and has 58% on the total market share in terms of framework adoption. KanbanIt is a concept of a scheduling system for lean manufacturing and just-in-time manufacturing. Derived from a Japanese word, it signifies a signboard or the physical board with lanes to track the activity. This system helps to improve and optimize the flow of work items.  XP (Extreme Programming)Originated by Kent Beck, Extreme Programming is a software development methodology conceived to improve the quality of the product and its capability to suitably adjust to the shifting needs of the stakeholders. It is a set of engineering practices. FDD (Feature Driven Development)It is customer-centric, iterative, and incremental, to deliver tangible software results often and efficiently. FDD in Agile encourages status reporting at all levels, which helps to track progress and results.  DSDM (Dynamic System Development Method)This has been developed to work on usual problems confronted by projects such as late delivery, rate overruns or the final outcome not being accepted by the clients. It is an Agile-based approach that is collaborative and flexible, yet remaining attentive on reaching goals and sustaining the suitable level of excellence and consistency.  What is the Scrum Methodology? Scrum is an agile project management framework that revolves around an incremental and iterative approach where the focus is on delivering increments in a time-boxed manner. Scrum supports the collaborative approach of working towards a solution and is based on the Agile Manifesto and principles. The Scrum framework comprises of: Three rolesScrum Master, development team and the product owner Scrum EventsSprint Planning, Daily Standup, Sprint Review, and Sprint Retrospective. ArtifactsProduct Backlog, Sprint Backlog, Task-Board, Burndown charts, Sprint Goal  Agile vs. Scrum: Similarities and Differences While Agile provides an umbrella for different frameworks that share common values and principles as prescribed by the Agile Manifesto, Scrum is a subset of Agile and has inherited the foundation and beliefs from its superset. Let us look at some of the similarities and differences between Agile and Scrum: AreaAgileScrumIs a Mindset/philosophyYesIs a FrameworkYesHas events/ceremoniesYesHas ValuesYesYesHas defined rolesYesFocus on Continuous ImprovementYesYesFocus on Faster DeliveryYesYesTransparencyYesYesCustomer SatisfactionYesYesBest practices in Agile Though Agile has certain principles and values to define how teams should function, it is also necessary to adhere to the best practices to get the finest implementation of the methodology. Here are some of them: Deliver in IncrementsIncrementing helps the teams and stakeholders stay in control of the development step-by-step. They discover and refine the backlog as they move forward rather than create a huge backlog upfront as was the case traditionally.  Frequent InteractionsCommunication is the key to success. The more collaboratively the team works along with the client, the more the satisfaction on both ends. This helps to meet the expected requirements and greater clarity on the next assignment. ReflectionIt is critical to introspect as an individual and retrospect as a team to see how they are functioning and what can be improved to make it much better. Best Practices in Scrum With extensive use of Scrum, organizations now have their own success stories along with a bundle of learning on what went well and where they had to struggle. This paved way for expanding the list of best practices one can follow to stay on track with the framework. To list out few: StoryBoardHave a live storyboard, let the team update their deliverables. The Scrum Master can help the team understand the value they can derive from it. Productive EventsStick to the agenda of the scrum ceremonies, make it timeboxed Capacity PlanningPlan your sprint as per the available capacity so that the teams are not overburdened. BlockersMake the impediments very much visible to all the stakeholders and the management. Backlog ManagementEffectively manage the backlog, as much as possible, refine, and prioritize. Strong AtmosphereCreate a collaborative healthy environment where the individuals can voice out their concerns. ImprovementContinuously improve the way team interacts and communicates with the clients Mirror Your workBe transparent and honest with the metrics and burndown charts amongst the team Follow scrum valuesThey really help in the long run. And last, but not the least, be agile! In conclusion While every framework is different, applying each one in the right spirit and context is the key to success.The Agile methodology is a fantastic way of working and is helpful to everyone involved. Best of all, it aims to help individuals attain their highest potential in terms of capacity and capability.  It is worthwhile reiterating that Agile is not limited to software development. It is a mindset and a way of life. And with the world constantly adapting to newer ways of working, Agile is the way to go!
Rated 4.0/5 based on 22 customer reviews
What is Agile? What is Scrum?
Blogs
11040
What is Agile? What is Scrum?

Over the decades, companies across the globe have ... Read More

Failures in Agile Transformation

With the increase in Agile adoption across the organization, the stories are piling up too. Now the question is, are these success stories or the failure stances. Usually, in the conferences or meetups, you get to meet people from various establishments, this is just another way of getting to hear what worked or what not. Even in your own organization, you can feel the pulse of the transformation. There are many reasons why we end up with messy transformation, I have tried elaborating few in the discussion today but there’s more to it. As you read, you might connect with some of the points, let’s start the digging:1. AIMING ON PROCESSES AND NOT PEOPLEThe inclination of Agile is more towards people or individuals, we talk about empowering team, making them self-organized. We even talk about creating high performing teams which can deliver maximum value by the end of every increment. With the adoption of Scrum, where the core values involve Focus, Openness, Respect, Commitment and Courage at the root level, the ‘people’ factor becomes important. Ultimately, it the ‘people’ who work at the ground level for client satisfaction, to achieve this, they adopt processes for smoother workflow. That’s it! Organizations, during their transformation, tend to overlook this critical piece. Their approach becomes more inclined towards processes and they start considering Agile as a process but in fact, Agile is more of a mindset change. Process starts getting priority over people or individuals, always remember, process is just for supporting or helping the individuals with their work. People are not for the processes, even one of the four principles in the agile manifesto says: “Individuals and Interactions over Processes and tools”. I was surprised to hear in one of the trainings’ that people in the same team are using mail to communicate around the stories/deliverables. Can we not give preference to face to face interactions?2. MICROMANAGING THROUGH CEREMONIESSelf-organization is one of entities in Agile, the core says, trust your teams. Micromanagement not only hinders creativity, but it also impacts the morale of agile teams. Management or the scrum master should refrain from getting into the minute details during the scrum ceremonies. Most of the times, it is observed that the daily scrum gets converted into a status meeting either for the scrum master or for the technical lead. As a Scrum Master, you should help the team getting self-organized rather than being directive. One of the principles from Agile talks about giving the space and trust: “The best architectures, requirements, and designs emerge from self-organizing teams.” This enables the team to find their own solutions, helps them with innovation and most of all, teaches them the value of being a team. Every ceremony has its own schema and none of the ceremony is to track individual chores. You must trust your teams, remember, trust can do wonders, believe me, if you trust your people, they will never let you down. Here comes another principles’ focusing on the same. “Build projects around motivated individuals. Give them the environment and support they need and trust them to get the job done.”3. Hastening the TransformationAny change, whether it is for the system or for an individual, takes time. When was the last time you promised yourself to change one of your habits, was that easy? Almost every individual at the start of the year takes so many resolutions, how many do you think gets accomplished! Same goes with the transformation, it takes time and you will have to give because it is not just about the individual, it is about the organization. When the transformation journey starts, the delivery teams take the maximum heat. They are the ones who are expected to be Agile BUT the management usually lags, they are still in need of mindset to support the change. Just by doing the agile ceremonies is not being Agile, it comes with a wide variety of shift, be it - culture, technical, management or team. You have to accept that it is going to be a challenging journey which will have its own milestones and you cannot skip those. Also, it is long journey with hiccups, be ready to accept the challenges, learn from the mistakes and come up with the action items to improve.4. Scrum Roles Getting a Back SeatWhen teams in agile are formed, some of the roles are asked to play dual. In such scenarios, scrum master roles can be played either by the team lead or by someone who is ready for that extra piece. Though the role gets played, but the essence of this position goes for a toss. The focus just stays on delivery without instilling the purpose.  The organisation needs to acknowledge that scrum master'sis a fulltime job that helps teams in staying on track, motivated and helps them see their own progress through information radiators. Anyone else playing a dual role might not do justice and end up walking on two different tracks - not able to reach the goal in both the positions. The team needs someone who can teach, mentor, train and be with them. Just forming the team is not enough if the organization doesn't follow the best practices, such cases tend to get trapped.5. Lack of support from Middle managementIn my past experiences with the organizations in transformation mode, usually the middle layer is where the problem brews. Transformations get a go ahead from the top layer, but it gets difficult for the middle management to adopt. It is important to ensure alignment among the leaders of the organization on the aspiration and value of the transformation is done before moving ahead with the approach. In another example we can see a project manager being insecure as most of the juggling is being handled by the scrum master. In such cases, to prove their existence, the middle layer starts getting into the little details, this impacts the team as half the time they are functioning as per the project manager. Due to this, we hear a lot about the role of scrum master being questioned on their responsibilities. They are assumed to be just sitting and watching, in other words, doing nothing! According to the research led by AgileTurkey.org in Turkey in 2018, the two major hindrances to agile transformation were found out to be the resistance to transformation and culture transformation. Existing managers have a lot to do in order to manage with these two major challenges, they should be part of the transformation beginning from themselves, their day-to-day actions, and should guide the whole company by being supportive of the process.6. Tools over mindsetWith the transformation comes the need to use fancy tools and abide by ‘laws of the tools. Some feel proud in using the costliest tool, some make it a point to introduce the tool being used by the competitor. But is it worth it? Transformation can be done using ‘MS Excel’, there is no set protocol for focusing on the tool. Though the tools play an important part, but teams should focus on Agility and Scrum framework first and then on tools. You certainly need to track metrics like velocity, burn-down, estimates. But with the right mindset, the goal can be achieved with no trouble. This doesn't mean tools are bad, but it means mindset should be given priority over the extensive use of tools.7. Transformation as a Destination (Thinking Your Transformation Is Done)Many a time, we hear ‘We are now agile, we transformed in so and so year’ and what not. But is agile a destination, NO, it a journey, a never-ending journey. Some teams think just by implementing a bunch of backlogs, doing the ceremonies and tracking metrics, they are Agile. No, they are not!Whatever way out we have today are based on our experience, knowledge and the situation we are in. If any of the factors change, our solutioning will be different. Both the values and principles of the Agile Manifesto point to the continuity of the process. Responding to change over following a plan relates appropriately as much to the processes as to our sprint outputs. We have to understand that process is never whole. You just have to continue reflecting what worked and how to fine tune the process whenever required.8. Misunderstood cross-functional teamEvery time I speak about the delivery teams, at least one of the participants from the audience ask this question “We say it's a cross functional team, but my tester is not ready to code!” Have we understood it correct? None of the processes are bad, it is about how we adopt them that makes a difference. “Cross Functional Doesn’t Mean Everyone Can Do Everything, a cross-functional team has members with a variety of skills, but that does not mean each member has all of the skills.”  – Mike Cohn. This interpretation of cross-functional imposes a pressure on the delivery team which breaks the team apart and is sometimes the cause of conflicts among the members. As per scrum guide – “Cross functional teams are groups consisting of people from different functional areas of the company. – it should be formed not only with technical specialists (Back-end, Front-end developers, QA engineers, etc.), but also consists of member like Business Analysts, Marketing and UX specialists or anyone else taking an active part in the project.”9. Scrum for AllJust because everyone is going that way doesn’t mean that way is for you too! It is necessary to understand the current and what exactly you want it to be once the journey starts.  Scrum is one of the frameworks to help with complex adaptive projects, but it is not for all the products or projects. If you are transforming your IT helpdesk department, scrum might come out as a failure, the support team cannot say that they will be delivering 10 high priority tickets after the end of sprint, where sprint duration ranges from two week to a month. Second scenario can be the team handling production defects. But this does not mean that Scrum is bad, no it is not. It is just that these scenarios are not meant for Scrum.Every story is different and so are the reasons, as said earlier as well, this is not just a complete list, there can numerous other details depending on the situation. I will be happy to hear your viewpoints on the misalignment and disorientation. Lastly, it is significant to focus more on the people, the mindset and the collaboration to get better results.
Rated 4.5/5 based on 5 customer reviews
Failures in Agile Transformation
Blogs
9014
Failures in Agile Transformation

With the increase in Agile adoption across the org... Read More

Scrum Epic: How to Split an Epic into Chunks in Agile?

Scrum has been a buzzword since a decade now, and why not, it has so many success stories, hey, I am not talking about the stories which mean requirements in Scrum but the actual stories of teams and the organizations practicing Scrum. Looks like, I just gave the hint of what I would be covering in my article today.Yes, we will be talking about the requirements and how are they handled in Scrum. We will be talking about the Epic, so far, we have known Epic as a long narrative about the heroes of great historical or legendary significance performing courageous deeds but here we will touch upon a different side. Believe me, we are now going to talk about the Epics in Scrum!What is an Epic in Agile?In simple terms, Scrum Epic in Agile Methodology is a big chunk of work which can be divided into smaller user stories. An Epic can be spread across sprints and even across agile teams. An Epic can be a high-level description of what the client wants, and accordingly, it has some value attached to it. As we mentioned, an Epic is a high-level requirement, hence its scope can change over the course of time.Epics are a helpful way to organize your work and to create a hierarchy. The idea is to break down the work into shippable pieces so that large projects can actually get done and you can continue to ship value to your customers on a regular basis. Epics help teams break their work down while continuing to work towards a bigger goal.- AtlassianTo explain it better, I would prefer taking a life example, let’s say, throwing a New Year party at your place can be an Epic requirement for you. To do so, you’ll need to organize your effort: from the biggest objectives down to the smallest details. You should be able to respond to change, report your progress, and stick to a plan. Once you are aware of the Epic, you can drill it down to create smaller tasks like creating a guest list, deciding on the menu, shopping grocery, decoration at home, shopping for the new year, etc.Let’s see how we can create an Epic also called Scrum Epic User Story – In today’s era, almost all the tools that the team use have the capability to create an Epic, it is up to the product and the team, which type of Epic they want.Some Epics cater to the reporting needs of management. Some Epics are created with a timeframe in mind, it should not be too long and too short, i.e. it should not take more than a couple of weeks to finish. But the widely used way is Storytelling. But, what is storytelling?What is Storytelling?Storytelling is a tool which helps you visualize the flow of events and how they corroborate back to the Epic. If you feel, your working pattern does not sit in any of the mentioned ways, create your own. Just remember, Agile is never prescriptive, it shows you the path and how you want to go over it, it’s your choice!Coming back to our example, let us try to break it down in some doable components. It is really important to create chunks out of the Epic, so that the team can pick those up and deliver in a Sprint period. You can compare this activity with an art which requires precision in terms of size, priority, minimally interdependent etc. There are some pre-set ways of doing it, like:Workflow break downHere in our example, we talked about a project where we have a New Year party, let’s see how we can break it down in terms of workflow – Shopping can be a workflow where you need to get the items from outside. Another workflow can be cooking the food for the guests, the same way we can have decorating the house as another workflow. See how simple it gets to understand once you start connecting it with our lives! This also helps the Product Owner to easily prioritize the work, in our case, the Product Owner can be the host of the party. Some steps in the workflow may not be important right now and can be moved to later stages. Perhaps baking the cake takes on the priority as it takes time to cool down but the same can be done later as well.Role-based breakdownWe can also break an Epic as per the role, there can be different roles in your product or a project, here we have a role of a ‘host’, ‘guest’ or you can have a role as a ‘cook’, you can even add the roles based on your product. In a role-based breakdown we talk in terms of that particular persona, e.g., for a host, ‘Driving a successful party’ can be one, for a guest, it can be, ‘Looking for some fun games at the party’.Break Down around the timelineSome of the Epics can be broken down according to the time it will take to complete. The team usually divides the work which can be accomplished in a sprint time. They take up the whole thing, break it into pieces and fit the pieces in different Sprints as per the dependency and priority.As I have already mentioned, breaking down the user stories, requires consideration into several areas such as size, priority, interdependency, etc. Thus, there are two approaches for dividing the user stories– Horizontal and Vertical. It is like cutting the cake, if you cut it horizontally, you will get a single layer but if you take a vertical approach, you will get to have a bit of all the layers.Understanding the basic differences between Epic, Story, and TaskWe have been talking a lot about Epic and its breakdown, now let’s capture how it actually disintegrates further. We had an Epic “New Year Party”, this was a big chunk of work to be accomplished, we learned about the techniques to break it down. The result of the breakdown is termed Stories, which can be accomplished in a sprint time. The stories are further broken down into chunks called ‘Tasks’, the team pulls up the tasks and complete them, once all the tasks are completed the story is marked as ‘Completed’. The below figure explains Scrum Epic Vs User Story:Thus,Epic - A requirement that is just too big to deliver in a single sprint. Epics need to be broken into smaller deliverables (stories).Story - A requirement that the business wants. It is something that is deliverable within a single sprint.Tasks - The essentials of a story, these are the milestones to take the story to ‘Done’.Anything that we cannot measure will not yield many results, we have been hearing this for a long time. It does apply here as well. We can use burndown charts to measure how much work has been accomplished in an Epic. This also helps in predicting if the team is on track with the commitments. By keeping a watch on the Burndown chart, it becomes easy to manage the progress and blockers (if any) that the team is facing. This not only provides transparency to the system but also helps in building the trust for the team and the clients.How to identify Epics in AgileEpic is something which is a fairly large chunk of work and cannot be completed in one go. It is something which requires discussion and brainstorming so that it can be broken down further into smaller chunks.At the Epic level, we give rough estimates which can be in the form of T-shirt sizes, swags, points or any other method the team is comfortable with. The team can track the progress in an Epic through the Burndown chart which represents the progress and also reflects if there are any blockers.Benefits of EpicsEpics help in understanding the high-level requirement from the Stakeholder and what exactly is the need.It also helps in defining the scope of work which is in agreement with the client. Epics articulate efficiently about the final output what user needs.Epics help to track bigger thoughts in a product backlog without swamping it with multiple things. They allow establishing a hierarchy for the backlog items where the Epic represents the original idea often closely related to a particular outcome.It also helps in estimating how much time it will take to deliver. Epics are time and again used as placeholders for new views that have not been thought out completely, or whose full expansion has been postponed till essentially desirable.Epics are then evolved into split into multiple user stories that help Agile development teams effectively manage and groom their product backlog.Common Pitfalls in EpicThough there are many positive aspects of using the Epics in backlog management, a coin always has two sides, it has its pitfalls too! Sometimes, the teams can create confusions around the end deliverable from the Epic by just viewing them as more than just large user stories. This is deceptive when the team creates multifaceted tools to distinguish between Epics and user stories as well as creates far-reaching tools for chasing Epics separately from other backlog items.The teams may also try to estimate the Epics at a very high level though they might not have a clear picture of what is to be done. This increases the chances of ambiguity and it is very likely that the estimates will not be of any use as it will not serve any purpose in reporting.Finally, here we are, with the discussions around the Epics and how we can break it down. There is no fixed way to work on the Epic, it is all about what approach suit your needs. Again, it is all about the mindset and an approach we use to deal with the backlog. Epics are always fascinating to work with!User story is the unit of work defined in Scrum. When a Product Owner writes a user story for the customer’s requirements, it looks pretty simple at an initial stage. But, while working on that user story, all the related tasks tends to increase a lot that it is unable to fit in a week sprint. In such case, you need to break down such big user stories in epic and start slicing the epic further in smaller user stories. This approach can ease the efforts of Agile teams to get smaller but quality outcome in single sprint.
Rated 4.5/5 based on 25 customer reviews
Scrum Epic: How to Split an Epic into Chunks in Agile?
Blogs
10231
Scrum Epic: How to Split an Epic into Chunks in Ag...

Scrum has been a buzzword since a decade now, and ... Read More

Reasons to Get Updated to Leading SAFe® 4.6 Certification in 2019

SAFe®️ is an agile framework for software development which encourages alignment, collaboration, and delivery across large numbers of agile teams. It was developed by Dean Leffingwell, leveraging three major bodies of knowledge: agile software development, lean product development, and systems thinking. It offers a simple, lightweight experience for the development team. The entire framework is distributed into four sections Team, Program Level, Large Solution, and Portfolio. The scalability and configurability provided by SAFe®️ framework support organizations to deliver new products, services, and solutions in the shortest sustainable lead time, along with the best potential quality. It orchestrates alignment, collaboration, and delivery for various Agile teams ensuring every team is focused on the same goal.With the increase in success rate for the organizations turning towards scaling, the need for them to equip themselves with the right tools, techniques, and people became their top priority. As we all know, from our experience, ‘people’ parameter is crucial for the success of any project or any organization. There has been a sharp upswing in the demand of certified professionals with the needed skills. The organizations are now turning to people who can demonstrate skills and qualities that can help them adopt the change smoothly. They are now looking into specific areas such as SAFe®️ Agilist who can understand the whole system, who can work with the teams and help out at the different levels in delivering a quality product that can add value to the customer. Most of us have already seen how SAFe®️ 4.5 works and its benefits, a good part is, now we have SAFe®️ 4.6 which highlights the introduction of the Five Core Competencies of the Lean Enterprise. Before looking at the advantages of Leading SAFe®️  4.6, we will see the new features in Leading SAFe®️  4.6.In addition to the core competencies, this updated version in Leading SAFe®️ includes new government guidance, which describes a set of success patterns that help public sector organizations implement Lean-Agile practices. Mastering the core competencies enables enterprises to successfully respond to volatile market conditions, changing customer needs, and emerging technologies. Let’s look at the advanced topics in SAFe®️ 4.6:SourceLean-Agile LeadershipLean-Agile Leadership lies at the very foundation of the framework defining how the Lean-Agile leaders will go about and endure the organizational transformation, to achieve this, they might need to create an environment of learning, exhibiting, teaching, and coaching SAFe®️’s Lean-Agile Mindset, values, principles, and practices. Among the five competencies being introduced, Lean-Agile Leadership forms the root of the framework. The lean-agile leadership comprises of managers, leaders, and executives who can drive the change and also to continuously work around the improvement needed. These leaders will base their working model on the core values as stated by the scaled agile framework which is alignment, built-in quality, transparency, and program execution. The leaders embrace the SAFe®️ Lean-Agile mindset which is the combination of beliefs, assumptions, and actions of leaders and practitioners who embrace the concepts in the Agile Manifesto and the SAFe®️ House of Lean. These leaders are the torch-bearers for the organizations in the transformation journey, making it clear where they are and where they need to go.Team and Technical Agility“Continuous attention to technical excellence and good design enhances agility.”—Agile ManifestoWhen we talk of making a team the high-performing, we need to understand what all is required in their transition, maybe some critical skills, principles, and practices to support current and future business needs. Let’s first understand what is team agility - cross-functional, responsible, and dedicated to collective goals, they have all the skills necessary to define, build, test, and deploy value in short iterations. Now, talking about it in terms of scaling, these teams become part of Agile Release Train (ART), these trains have necessary people to drive towards the solution. They plan, integrate, demo, deploy, release, and learn together.This was about the team functioning, now let’s move to technical agility, which is, “defines the Agile software engineering principles and practices teams use to deliver solutions quickly and reliably. This includes the Lean-Agile values and principles, eXtreme Programming (XP) practices, Behavior-driven Development (BDD), Agile modeling, built-in quality, proven approaches and patterns for object-oriented software design, and more” – Scaled Agile.DevOps and Release on Demand“It is not the strongest of the species that survive, nor the most intelligent, but the one most responsive to change.” —Charles DarwinDevOps is the recipe of traditional values, practices, and tools that upsurges an organization’s capability to provide product and services at high velocity: progressing and refining products at a quicker speed as compared to organizations using traditional software development and infrastructure management processes. This swiftness permits organizations to better help their clients and compete more successfully in the market. The benefits of DevOps include speed, rapid delivery, reliability, scaling, improved collaboration, and security. SAFe®️ talk about the ‘CALMR’ approach and is grounded in five concepts - Culture, Automation, Lean flow, Measurement, and Recovery. Each concept serve as the foundation pillar for DevOps and in turn, helps with the continuous delivery pipeline. Release on demand is the method through which new functionality is deployed into production and released immediately or incrementally to Customers based on demand. ARTs and Solution Trains can continuously explore user value, integrate and demo value, deploy to production, and release value whenever the business needs it.“Showing a strong success and visible benefits is key to getting others to agree to try your way of doing things.”—Frederic RivainBusiness Solutions and Lean Software EngineeringDefinition as per Scaledagile – “The Business Solutions and Lean Systems Engineering competency describes how to apply Lean-Agile principles and practices to the specification, development, deployment, and evolution of large, complex software applications and cyber-physical systems.”Earlier when the organizations followed the traditional approach, the cycle time from the birth of an idea to its delivery took enormous time, most of the times the originator of the idea or the teams working on it went for a complete change, it even sometimes took a lifetime(Phew). Now, we can understand why there were late deployments, budget going over the bounds and issues with quality. This typically consequences in higher than expected maintenance and operations expense, poorer returns, and other business complications.To deal with it, Scaled Agile Framework gives the direction of building up large-scale solutions in a flow-based, value delivery-focused model, driven by Lean and Agile principles. The principles provided by Scaled Agile Framework relate directly to the development of all kinds of large and complex systems. They have embedded Lean-Agile values and principles to make sure the customer gets the right value at the right time with the best quality.Lean Portfolio Management“We don’t have to be smarter than the rest. We have to be more disciplined than the rest.” – Warren BuffettLean Portfolio Management (LPM) is one of the Five Core Competencies of the Lean Enterprise and it rests at the Portfolio level. This area focuses on how an organization can embrace Lean approaches at the strategic, financial level, Agile portfolio operations, and Lean governance. The Lean Portfolio Management function carves out its way through a series of three collaborations—strategy and investment funding, Agile portfolio operations, and Lean governance— this enables the organization’s ability to accomplish current obligations consistently and enable innovation by building on the foundation of the four other core competencies. LPM is the process of running a program and product portfolios by applying the concept of lean thinking. This result-oriented method delivers high-quality work by prioritizing and managing the work in the Lean portfolio. It increases the speed of planning and reporting processes and eliminates the time-consuming governance.Features of LPM include:Prioritization of the most valuable and critical activitiesTimely inspections and validation of workQuick delivery of high-value work without interruptionsTask alignment with the company's objectivesIn my point of view, this is one of the finest framework developed so far which takes care of the components that other frameworks missed incorporating. It truly focuses on people and product, bringing both of them to rise in terms of skills or qualifications. With this new addition, the agile teams can enhance the way they work and also THEMSELVES. It takes care of all the levels in the framework, enriching every stage with the refined thought process and Lean-Agile way of working. Starting at the team level and working up towards the Portfolio is truly amazing, along with an emphasis on a value being delivered, it also works on creating a healthy environment for the agile teams to deliver the best of quality. It has the best practices embedded with the framework to support both the stakeholders and the teams by building a Continuous Delivery Pipeline and DevOps culture. Scaled Agile Framework is a large knowledge base of demonstrated principles, competencies and practices, that are assimilated together to help bring about cultural change in organizations, which means the teams will deliver faster, more frequently, on time and on budget. Whether you believe it or not, SAFe®️ has some truly convincing case studies which prove its claims!!I have experienced how SAFe®️ helps organizations scale tremendously, I have witnessed the culture shift and the mindset change and with this new version, I can say, go for it, it will really benefit the way you think and the way you work. With the refined version, you will get to see a new way of delivering the best quality.This upgrade is the need of time! I would like to end this with a lovely quote,“Quality debt focuses on the impact of implementation and quality decisions on the end user and business; how those decisions affect their ability to do their day-to day-job.”— Jordan Setters
Rated 4.5/5 based on 13 customer reviews
Reasons to Get Updated to Leading SAFe® 4.6 Certification in 2019
Blogs
12524
Reasons to Get Updated to Leading SAFe® 4.6 Ce...

SAFe®️ is an agile framework for software devel... Read More