This Festive Season, enjoy 10% discount on all courses Use Coupon NY10 Click to Copy

Search

Trending blog posts

How Does the Implementation of Leading Safe®️ 4.5 Benefit Organizations?

     "Necessity is the mother of invention – Plato”   This quotation even applies to our software development where things are changing fast and it’s not just an elephant that you have to deal with, it’s the “Titanosaur Argentinosaurus huinculensis” – the massive dinosaur.The software industry has grown by leaps and bounds which implies that the challenges have even multiplied too. For large programs and organizations, the challenges can come from any of the corners, it can be around monitoring or control, communication, stakeholders onboarding, change management, governance structure, the list is pretty long, and any imbalance can impact any of the three sides of the project management triangle – time, cost and scope.With a volatile industry, Scaled Agile Framework (SAFe®️) came in as a big rescue for the teams working on the different sizes of solutions. It is an ability to help the teams in maintaining an alignment with the business goals. Also, helping the organizations that need to work across the teams, is totally praiseworthy. Being deep-rooted in Agile and Lean principles, scaled agile remains more effectual than traditional styles to software delivery.Before the Agile era, we used to build the large and complex systems and the effects were outraging. Most of the times, the teams were missing the deadlines and minimal focus was given on a quality. Due to this, businesses faced bad days and I feel the software industry regrets that now.Measuring SAFe®️ business benefits, SAFe®️ tries to address these issues and companies who have adopted the framework have shown amazing results. With the need of delivering quality, time-to-market, faster ROI, our leaders in the industry shaped in a lot models and frameworks to support software development like Large Scale Scrum (LeSS), Disciplined Agile Delivery (DAD) etc.The flexibility these frameworks provide may valued by those with a good understanding of agile, but it might not offer sufficient track for those who are transitioning from traditional models. The usual reason we get to see for agile failure lies in the mindset of cultural change, none of the framework apart from SAFe®️, takes care of this fact.Back in 2011, Dean Leffingwell and Drew Jemilo, together came up with the framework which has helped a wide variety of organizations, so far, they stay strong with their framework by introducing new features and making it more compatible with the needs of the organization.The advantages of Scaled Agile Framework, if taken into account, the ‘Full SAFe®️’ takes care of all the levels in the organization and provides end-to end solution at the organisation level. Scaled Agile Framework was designed to sustain the big picture view of software development, it can effortlessly handle a synchronized plan for large-scale and complex projects with teams that can go beyond hundreds.Organizations can opt the benefits of Scaled Agile Framework, if their focus is on scaling the agile processes up to enterprise level, aligning business and technical goals for the company, utilizing the employee skills effectively, defining effective organizational structures around agility, scheduling for on-time delivery and improving the quality of solutions.It is the framework which not only aligns at the team and program level but also helps us stay aligned with organization strategy. It provides different level of configurations, that organizations can pull as per their needs. Scaled agile framework highlights predominant fears, like architecture, security, performance, and the resolution of dependencies and inconsistencies across the projects.In this framework we talk about releases, trains, value stream, product increment, the reasons to consider SAFe®️, and each and every entity in the whole system is connected to deliver the best solution.I have been a part of the transformation, where our organization moved into scaled framework, it is actually a big change, a big shift from what we were earlier. Now, there was a proper alignment in terms of product, teams and the work assignment. Teams actually understood why we are building it, they got to know what value it is going to add as a whole.As a culture shift, everyone was talking a foreign language but surprisingly they could easily comprehend the whole shift. You can feel the excitement, the lows and highs, the overall chaos in the initial phase and a smooth runway in a longer run.But it takes time, I just mentioned complete 2 years journey in a paragraph!!So far, I have been just talking about ‘what’ and ‘why’ for scaled agile framework, now let’s look into the ‘how’ part of it relating to the business. Trust me, this framework is really huge and the more you dive into it, the more you will be astonished by its beauty and effectiveness.Talking about the business, the organization's main focus is usually on the productivity (output), quality, time-to-market and the engagement. These are the basic reasons for any businesses for adopting SAFe®️ in the organizations. As per the survey, the productivity of your teams increase in the range of 20% to 50%, this owes to the fact that the teams have to be aligned with the product, the continuously collaborate and interact which gives them a high level of transparency on the expectations, they understand the deliverables and in turn set the expectation of the stakeholder too.This framework takes care of the dependencies and complexity which helps in building more. This helps in aligning the right work to the agile teams, even the customer knows what to expect at the end of the release, hence the balance in work assigned and the work delivered greatly increases, and it comes back as an increase in the productivity.Quality is one of the foundations when we talk about SAFe®️, organizations using SAFe®️ reported an increase in quality ranging from 20% to 75%, ‘wow’ factor for any company.“Continuous attention to technical excellence and good design enhances agility. Built-in quality is also a core principle of the Lean-Agile Mindset, helping to avoid the cost of delays (CoDs) associated with recalls, rework, and fixing defects. SAFe®️’s built-in quality philosophy applies systems thinking to optimize the whole system, ensuring a fast flow across the entire Value Stream, and makes quality everyone’s job.” – Scaledagileframework.com.Quality is embedded at every stage/level in SAFe®️, it can be dev tests, QA tests (scale, security, UAT), environment tests or prod config. A continuous delivery pipeline ensures quality before delivery into production. The scale agile framework also helped in getting happier teams with their satisfied stakeholders.Now, the teams have more visibility into what is building in and why is it building. Constant collaboration at all levels increases the confidence and raises the commitment. Most of the times, the teams actually get to interact with the real customers which helps them own the product and its deliverables, they tend to feel elated about showcasing what they have developed.As I have mentioned earlier, this topic is really vast, but, not a problem, I will try to give you an insight touching up from a birds’ eye view. Let’s move on to see the real examples that we have from the organizations which adopted SAFe®️, and yes, it was not a smooth drive for them initially!In this article, we will cover the case study from LEGO - It is a line of plastic construction toys that are manufactured by The Lego Group – the company we all love so dearly!When LEGO adopted its scaled agile journey in 2015, they started their journey with moving 5 teams out of 20 to get into self-organizing mode. And later on the other teams followed the journey, but there was a challenge on coordination and collaboration. To make that happen, LEGO followed the SAFe®️ framework pattern and added another level of abstraction- the program level. They followed few practices such as meeting in every 8 weeks for a planning session which lasted for one and a half days.During this meeting, teams showcased their work, worked out the dependencies, estimated risks, and planned for the next release period. With their adoption on scaling, they found the following benefits of Scaled Agile Framework-The team was now more confident on giving the estimates and precise predictability on the delivery of their committed work.The employees felt more empowered to accomplish their work. They focused on adopting lean practices and minimized the documentation and other productive work.They leveraged all the possible options for face-to-face communication and it really had a constructive impact on the way they worked and collaborated, increasing their efficiency and effectiveness.Another plus point was the use of visual boards which helped them stay focused.Other success stories are from FitBit, Accenture, Bank of Canada, TomTom, Capital One, Sony, Cisco. The list is pretty long and has been increasing continuously. Every organization has a story to tell from their transformation journey. Being agile is not a destination, but it is a continuous journey. So, be a part of the scaled journey and enjoy the Scaled Agile Framework pros.Summarizing all the aspects that we have been discussing so far, the crux of adopting the scaled agile framework could be, better predictability, higher productivity, increased quality, greater employee happiness, faster time to market.This framework can be adopted by the larger organizations, we have already witnessed awesome feedbacks from companies implementing SAFe®️, though it has got its own set of prescription, it really helps if the values and principles suggested by the framework are applied at its best. Scaled framework supports the organization at all the levels ensuring they deliver excellence at every stage.
How Does the Implementation of Leading Safe®️ 4.5 Benefit Organizations?
Deepti
Rated 4.0/5 based on 11 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

How Does the Implementation of Leading Safe®️ 4.5 Benefit Organizations?

     "Necessity is the mother of invention – Plato”   This quotation even applies to our software development where things are changing fast and it’s not just an elephant that you have to deal with, it’s the “Titanosaur Argentinosaurus huinculensis” – the massive dinosaur.The software industry has grown by leaps and bounds which implies that the challenges have even multiplied too. For large programs and organizations, the challenges can come from any of the corners, it can be around monitoring or control, communication, stakeholders onboarding, change management, governance structure, the list is pretty long, and any imbalance can impact any of the three sides of the project management triangle – time, cost and scope.With a volatile industry, Scaled Agile Framework (SAFe®️) came in as a big rescue for the teams working on the different sizes of solutions. It is an ability to help the teams in maintaining an alignment with the business goals. Also, helping the organizations that need to work across the teams, is totally praiseworthy. Being deep-rooted in Agile and Lean principles, scaled agile remains more effectual than traditional styles to software delivery.Before the Agile era, we used to build the large and complex systems and the effects were outraging. Most of the times, the teams were missing the deadlines and minimal focus was given on a quality. Due to this, businesses faced bad days and I feel the software industry regrets that now.Measuring SAFe®️ business benefits, SAFe®️ tries to address these issues and companies who have adopted the framework have shown amazing results. With the need of delivering quality, time-to-market, faster ROI, our leaders in the industry shaped in a lot models and frameworks to support software development like Large Scale Scrum (LeSS), Disciplined Agile Delivery (DAD) etc.The flexibility these frameworks provide may valued by those with a good understanding of agile, but it might not offer sufficient track for those who are transitioning from traditional models. The usual reason we get to see for agile failure lies in the mindset of cultural change, none of the framework apart from SAFe®️, takes care of this fact.Back in 2011, Dean Leffingwell and Drew Jemilo, together came up with the framework which has helped a wide variety of organizations, so far, they stay strong with their framework by introducing new features and making it more compatible with the needs of the organization.The advantages of Scaled Agile Framework, if taken into account, the ‘Full SAFe®️’ takes care of all the levels in the organization and provides end-to end solution at the organisation level. Scaled Agile Framework was designed to sustain the big picture view of software development, it can effortlessly handle a synchronized plan for large-scale and complex projects with teams that can go beyond hundreds.Organizations can opt the benefits of Scaled Agile Framework, if their focus is on scaling the agile processes up to enterprise level, aligning business and technical goals for the company, utilizing the employee skills effectively, defining effective organizational structures around agility, scheduling for on-time delivery and improving the quality of solutions.It is the framework which not only aligns at the team and program level but also helps us stay aligned with organization strategy. It provides different level of configurations, that organizations can pull as per their needs. Scaled agile framework highlights predominant fears, like architecture, security, performance, and the resolution of dependencies and inconsistencies across the projects.In this framework we talk about releases, trains, value stream, product increment, the reasons to consider SAFe®️, and each and every entity in the whole system is connected to deliver the best solution.I have been a part of the transformation, where our organization moved into scaled framework, it is actually a big change, a big shift from what we were earlier. Now, there was a proper alignment in terms of product, teams and the work assignment. Teams actually understood why we are building it, they got to know what value it is going to add as a whole.As a culture shift, everyone was talking a foreign language but surprisingly they could easily comprehend the whole shift. You can feel the excitement, the lows and highs, the overall chaos in the initial phase and a smooth runway in a longer run.But it takes time, I just mentioned complete 2 years journey in a paragraph!!So far, I have been just talking about ‘what’ and ‘why’ for scaled agile framework, now let’s look into the ‘how’ part of it relating to the business. Trust me, this framework is really huge and the more you dive into it, the more you will be astonished by its beauty and effectiveness.Talking about the business, the organization's main focus is usually on the productivity (output), quality, time-to-market and the engagement. These are the basic reasons for any businesses for adopting SAFe®️ in the organizations. As per the survey, the productivity of your teams increase in the range of 20% to 50%, this owes to the fact that the teams have to be aligned with the product, the continuously collaborate and interact which gives them a high level of transparency on the expectations, they understand the deliverables and in turn set the expectation of the stakeholder too.This framework takes care of the dependencies and complexity which helps in building more. This helps in aligning the right work to the agile teams, even the customer knows what to expect at the end of the release, hence the balance in work assigned and the work delivered greatly increases, and it comes back as an increase in the productivity.Quality is one of the foundations when we talk about SAFe®️, organizations using SAFe®️ reported an increase in quality ranging from 20% to 75%, ‘wow’ factor for any company.“Continuous attention to technical excellence and good design enhances agility. Built-in quality is also a core principle of the Lean-Agile Mindset, helping to avoid the cost of delays (CoDs) associated with recalls, rework, and fixing defects. SAFe®️’s built-in quality philosophy applies systems thinking to optimize the whole system, ensuring a fast flow across the entire Value Stream, and makes quality everyone’s job.” – Scaledagileframework.com.Quality is embedded at every stage/level in SAFe®️, it can be dev tests, QA tests (scale, security, UAT), environment tests or prod config. A continuous delivery pipeline ensures quality before delivery into production. The scale agile framework also helped in getting happier teams with their satisfied stakeholders.Now, the teams have more visibility into what is building in and why is it building. Constant collaboration at all levels increases the confidence and raises the commitment. Most of the times, the teams actually get to interact with the real customers which helps them own the product and its deliverables, they tend to feel elated about showcasing what they have developed.As I have mentioned earlier, this topic is really vast, but, not a problem, I will try to give you an insight touching up from a birds’ eye view. Let’s move on to see the real examples that we have from the organizations which adopted SAFe®️, and yes, it was not a smooth drive for them initially!In this article, we will cover the case study from LEGO - It is a line of plastic construction toys that are manufactured by The Lego Group – the company we all love so dearly!When LEGO adopted its scaled agile journey in 2015, they started their journey with moving 5 teams out of 20 to get into self-organizing mode. And later on the other teams followed the journey, but there was a challenge on coordination and collaboration. To make that happen, LEGO followed the SAFe®️ framework pattern and added another level of abstraction- the program level. They followed few practices such as meeting in every 8 weeks for a planning session which lasted for one and a half days.During this meeting, teams showcased their work, worked out the dependencies, estimated risks, and planned for the next release period. With their adoption on scaling, they found the following benefits of Scaled Agile Framework-The team was now more confident on giving the estimates and precise predictability on the delivery of their committed work.The employees felt more empowered to accomplish their work. They focused on adopting lean practices and minimized the documentation and other productive work.They leveraged all the possible options for face-to-face communication and it really had a constructive impact on the way they worked and collaborated, increasing their efficiency and effectiveness.Another plus point was the use of visual boards which helped them stay focused.Other success stories are from FitBit, Accenture, Bank of Canada, TomTom, Capital One, Sony, Cisco. The list is pretty long and has been increasing continuously. Every organization has a story to tell from their transformation journey. Being agile is not a destination, but it is a continuous journey. So, be a part of the scaled journey and enjoy the Scaled Agile Framework pros.Summarizing all the aspects that we have been discussing so far, the crux of adopting the scaled agile framework could be, better predictability, higher productivity, increased quality, greater employee happiness, faster time to market.This framework can be adopted by the larger organizations, we have already witnessed awesome feedbacks from companies implementing SAFe®️, though it has got its own set of prescription, it really helps if the values and principles suggested by the framework are applied at its best. Scaled framework supports the organization at all the levels ensuring they deliver excellence at every stage.
Rated 4.0/5 based on 11 customer reviews
How Does the Implementation of Leading Safe®️ 4.5 Benefit Organizations?
Blogs
6348
How Does the Implementation of Leading Safe®️ 4...

     "Necessity is the mother of invention –... Read More

Roles And Responsibilities Of A Product Owner You Should Be Aware Of

A Product Owner is a role in a product development team or a scrum team who is responsible for the product backlog, making sure that it is up-to-date in terms of priorities and has the items which translate back to the vision. The Product Owner represents the business or user and is accountable for collaborating with the consumer to define what features will be in the product release.What do Product Owners do?Since the time I embraced agile, I got to work with several Product Owners and mind you, this role is really critical as it handshakes at both the ends – the development team and the stakeholders. The Product Owner works with the stakeholders to get the right requirements, right in the sense, help the users to devise the requirements which they might not see or comprehend at that point. This not only improves the relationship with our customers but also helps to build up the trust. And at the other end, the Product Owner helps the delivery team/development team understand the vision and the requirements. Hence, this role is kind of a bridge between the two ends, holding tight the two corners and effectively enhancing the smooth communication.Roles and Responsibilities of Product OwnerAccording to Roman Pichler, the ultimate responsibility of a product owner is to ensure that the product creates value for its customers and users, as well as for the company. “Think of the product owner as the person who champions the product, who facilitates the product decisions, and who has the final say about the product,” he says. “This includes if and how feedback is actioned, and which features are released.”The role and responsibilities of a Product Owner are too deep so as to make sure he/she understands the core of the product and too wide that collaboration is done at 360-degree level, being a liaison and face of the user.Let’s look at the major responsibilities that this role demands:1. Defining the vision   The Product Owner has the responsibility of creating a vision so that the development team clearly visualize the expected outcome by the user. It is the Product Owner who majorly interacts and collaborates with the users to understand their requirements, thus, it is really important to translate this in a form of a vision to the team. Also, it is equally significant, to communicate to the stakeholders the vision and goals so that every talk the same language and have an identical understanding of the outcome. To make sure every item from the goal is aligned to the business objectives, the Product Owner should create a product roadmap, which is a high-level, tactical graphical summary that shapes the vision and direction for the product.2.  Managing the product backlog   The most essential responsibility in a role a Product Owner is managing the product backlog. Today’s market is really dynamic, every customer wants to stay at the top of the new features being introduced. Even the items in the product backlog might require some movements due to changing priorities. It’s the Product Owners responsibility to build up a stack of items in the backlog and prioritize them as per the business goals and the global approach. The product backlog is a dynamic list of items and as we call it in agile, it is ‘live document’ that should be frequently updated based on changing project requirements all the way through development.3. Prioritizing needs  Making choices about the priority of product backlog items in order to deliver the maximum outcome. The Product Owner has to order the items in the Product Backlog to best achieve goals and missions. We live in a world where help is readily available in term of awesome tools, hence, there are heaps of tools to help Product Owners do this. The Product Owner is required to have the Backlog sequenced prior to the Sprint Planning Meeting. This means that each user story must be ordered by relative importance.4. Overseeing development stages    Once we have the basic entities in place – vision, product backlog, and the prioritization, the product owner has to make sure that he/she is participating in the overall development stages of the product. The team might need their Product Owner to get the clarity on a few queries or they might need to demo the committed item. The Product Owner will participate in the ceremonies with the team, in some ceremonies, this role can be active such as planning or backlog grooming but can be passive or inactive such as in the daily scrum.5. Anticipating client needs  In today's’ competitive environment, it is really important for someone in a role of a Product Owner, to understand the client/customer’s needs. The product owner should understand the market, the competition, and the users’ pain points. With those valuable pieces of information, the product owner can determine what features should be implemented, and in what order, with respect to time and importance. Sometimes the Product Owner can help the customers configuring and penning down the items which they want but are not able to comprehend. And here communication plays a big role.6. Acting as primary liaison  As we have talked about this at the start of our discussion, a product owner role is more into acting as a primary liaison between the teams and the customers. The person in this role has to make sure the information flow is quick and clear so that there is no interpretation or reading between the lines. The Product Owner has to make sure that the goal and the vision are correctly aligned with the work items on the product backlog. The Product Owner also acts as a liaison for business stakeholders and end-users, determining whether each story meets their shared expectations.7. Evaluating product progress at each iteration   The product owner makes sure that the development works upon the priorities and monitors the progress of the items over the course of a sprint. Work that is either not complete or un-done needs to be re-prioritized or sequenced. The Product Owner makes sure that the development delivers the expected outcomes from the stories they worked upon and accepts it.8. Participates in the daily Scrums, Sprint Planning Meetings, and Sprint Reviews and Retrospectives Scrum ceremonies give a chance for the Product Owner to inspect and adapt. And as a result being present at these ceremonies is identical to success. It is important for the product owner to join the scrum meetings, it not only keeps the development team up-to-date with the priorities but also helps the product owner understand the perspective of the team if there are any impediments.9. Terminates a Sprint if it is determined that a drastic change in direction is required  If the Sprint goal has no meaning (will not deliver business value) because of the extreme change, the product owner can terminate the sprint. The termination is most frequently the outcome of an intense change in business priorities--something previously considered important is no longer important, or something even more significant is learned.How to become a Product Owner?Getting into a product owner not only requires a thorough understanding of the product but it also takes into account the analytical and strategic skills. The person who wants to deep dive and become a good product owner needs to understand the market and the stakeholders, he/she should be able to create a vision and knows when to juggle with the items in the product backlog so that the bucket is always prioritized.You can opt for some good certification programs provided by different authorities and gain a confidence in this area. As per my experience, I would recommend to select a domain, stick to it, master it by all means and then there is no stopping for you!What is Certified Product Owner?As defined by the Scrum Alliance, a Certified Scrum Product Owner (CSPO) is someone who has been taught by a Certified Scrum Trainer about the Scrum terminology, practices, and principles that will enable them to fulfill the role of Scrum Product Owner.Is the Product Owner the Project Manager?Both a project manager and a product owner watch over teams who work to carry developments across the finish line together. But the path to that finish line deviates entirely from the start. The product Owners are product driven and customer focused. The product owner needs to be actively engaged with the team because they are the ones responsible for deciding what features will go into the final product.What challenges does a Product Owner come across?As everyone in the Agile teams, the Product Owner also has a few challenges to tackle with, let’s talk about few of them:1. Missing product roadmap2. High-level acceptance criteria3. Spending too much time dealing with product support instead of grooming the backlog4. Changing priority while sprint is in progressProduct Owners can escape these usual snares by working around the product roadmap, centering on high-value backlog items, defining crisp acceptance criteria, concentrating on grooming quality backlog item, and avoiding disturbing sprints.The Future of Product OwnerThe role of a Product Owner is indispensable for the scrum teams, this role can be compared to a deeply rooted tree which has a firm foundation on the product side and provides vision, approach, and planned execution on the outer side. The product owners carry the ownership of the product in terms of quality and delivering as per the expectations set with the stakeholder.Product Owner needs to have an all-inclusive view of the product along with all the other factors that make product successful which involves understanding business, go-to-Market, organizational readiness, and product capabilities. All of these should be collectively managed, coordinated and aligned to drive product success.
Rated 4.0/5 based on 14 customer reviews
Roles And Responsibilities Of A Product Owner You Should Be Aware Of
Blogs
5897
Roles And Responsibilities Of A Product Owner You ...

A Product Owner is a role in a product development... Read More

Top 5 Scrum Estimation Techniques- Find Your Best Fit

Estimation, the very word in itself seems quite heavy, and it does feel substantial when you are asked to estimate unfamiliar items to some degree. One of the key advantages of adopting Agile is the capability of the team to estimate work effectually. Earlier when the teams were on waterfall, they used bottom up approach with the smallest tasks at the bottom, in order to determine the cost of each feature. On the contrary, Agile uses two estimation techniques, such as Top-Down Estimation and Relative Sizing, since we are not concerned about the detail of the tasks. Instead, we are much more interested in swift estimates of higher-level features, or even epics.What is Estimation?“Estimation (or estimating) is the process of finding an estimate, or approximation, which is a value that is usable for some purpose even if input data may be incomplete, uncertain, or unstable. The value is nonetheless usable because it is derived from the best information available.” – Wiki.As a part of the Scrum process, the development team sits together in the planning session, pulls out the items as per priority from the backlog and associates an estimate to the PBI (Product backlog item). The size of the PBI is projected in terms of User Story Points.I remember when my teams used to be quite first-hand at the concept of estimating the efforts, in the initial days, I could sense the uneasiness and question mark on their faces, it is the hardest part if implemented in true sense. But once they get used to it, they regain confidence.Estimation is necessary for any planning practice;Why to estimate?In my last session on estimate, I asked, why do we estimate and the answers I received were-To get people liable for their workTo predict the finish lineTo fill up the sprint with workTo measure teams’ progress we do estimationAnd lastly, because that’s what we do in estimation in Agile, right? (Partially true)But in true sense, estimates are required to plan work and time. It even helps the team to measure success in terms of numbers. Surprised! Yes they do project success, through velocity, sustained velocity figures, up rise in the numbers. Estimates can be turned into release plans too!! Even they help you make weighty decisions.“Estimating isn’t about estimating at all. Estimating is about creating a shared understanding of the requirements, and a shared understanding of the solution. When teams have problems estimating, it’s almost never an estimating problem, it’s a shared understanding problem” - MIKE COTTMEYERHow to Estimate?Estimating work items for new teams gets quite difficult as the teams are unfamiliar with the requirements and require solution but over the time, as team members get used to the product, they develop a progressively precise sense of how they’re going to approach stories and how much effort each user story will take to complete.As human beings, we are typically good at relatively estimating the items, e.g. we cannot predict at first instance if the Earth is heavier than Mercury, because heaviness is dependent on density which is not a visual thing to determine but we can confidently say that the circumference of Earth is bigger than that of Mercury as size is can be determined easily by visualization. Hence, we can relatively estimate the size of earth in comparison to the Mercury just by looking at it. Let’s consider the image below which shows how the product can be estimated. Teams across the world use a variety of methods to estimate their work. You just have to find the right way of doing it, or rather the way which is most suitable for your team’s need. There is no fixed rule for estimation and luckily we live in a planet where options are not scarce and this applies to estimation as well!Types of estimation techniques:Accordingly, I will now be discussing some of the methods which I have personally used with my teams. Starting off with the one which is being widely used across the globe:1) Planning PokerPlanning Poker is an Agile estimating and planning technique that is based on an agreement from the team on the points being assigned to the PBI. It makes sure that everyone participates and that every individual in the team shares his/her opinion.To start with, each team member is given a set of cards with numbers on them. The numbers are usually in the Fibonacci sequence: 0, 1, 2, 3, 5, 8, 13, and 21. The product owner reads out the story, after which, everybody in the team is asked to hold up the card showing the level of effort that they believe this story holds. Once all the votes are in, the team members with the lowest and highest estimates explain why they choose their numbers. The team then re-estimates as per the new perceptions discussed. Once the agreement has been reached that score is recorded with the story to which it relates, the team is good to proceed.2) T-Shirt SizesThis is a seamless technique for estimating a huge backlog of relative large items. T-shirt sizing is based on the concept of binning- a technique for accurately grouping together items of similar size. The bins are typically allocated labels matching to those commonly used with T-shirt sizes: extra small, small, medium, large, extra-large, etc.The primary advantage to t-shirt sizes is the ease of getting started. T-shirt sizes can be a great way of becoming familiar to relative estimating. So, you can start with it if your team finds that easier.3) The Bucket SystemMuch quicker than planning poker is the Bucket System. This system is a decent substitute when estimating a large number of items with a large group of participants quickly. Different buckets are created with values: 0,1,2,3,4,5,8,13,20,30,50,100, 200. The stories need to be placed within these where the estimator finds them suitable. The group estimates the items by placing them in these “buckets”. Buckets are usually different sheets of brown paper where you can place the sticky note with the item. But you can also use actual baskets to limit discussion about already processed items.4) Large/Uncertain/SmallA very fast method of rough estimation is the Large/Uncertain/Small method. The team categorizes the items as per being Large/Uncertain/Small, starting with populating the extreme categories. Following which, the group can discuss the more intricate items. This is actually a generalization of the bucket system. The system is especially good to use in smaller groups with comparable items.5) Dot VotingWhen there is a relatively small set of items and you don’t want any complex techniques, you can opt for Dot Voting. This method has been coined from decision making and can be used for estimating. Each person gets a small number of stickers and can choose to vote for the individual items. More the dots, bigger is the size. This method is very simple and fast, it will work effectively to assess a small number of stories (up to 8-10).ConclusionThere are many techniques that the teams use globally to estimate their work, here we have discussed the top five but there is no consensus over which method is best. Each method has its own advantages and has been customized as per the team’s functioning pattern. Like there is no common medicine that applies to all ailments, in the same way, there is no single method that applies to all for estimating. A facilitator has to understand that estimation takes time to sink in with the teams and it should not be forced upon. Go for the one which best suits your team’s need and at the same time, can provide optimum results.Happy Estimating!
Rated 4.0/5 based on 2 customer reviews
Top 5 Scrum Estimation Techniques- Find Your Best Fit
Blogs
255
Top 5 Scrum Estimation Techniques- Find Your Best ...

Estimation, the very word in itself seems quite he... Read More

Miscalculating Agile: Would You Choose Facts Or Opinions?

As rightly it’s been quoted “Easier said than done”, it’s quite effortless to mention that you are AGILE. Having witnessed organizations swearing on being Agile, it gets hard to believe them when you actually dive into the depths of the team’s delivery/functioning framework.Or it’s just a fancy term which makes you look like a newly renovated facade of RV attracting a horde of spectators (potential/existing clients) with a malfunctioning interior.Recently, I’ve started putting together a little list and there are a dozen reoccurring myths that haunt almost everyone who has witnessed what true Agile corroborates.1) AGILE IS A NEWBIE IN TOWNWhile attending one of the sessions a few months back, I was astonished to know that Agile exists since the time human evolved!! Isn’t that an exciting discovery, we always knew but never thought in those terms? Humans inspected the situations/conditions and adapted themselves as per the requirement or need of the time.                                                                                                                                                                                                            Jon Kern, an aerospace engineer in the 1990s, became persistently frustrated with the long lead times and with the decisions made early in a project that couldn't be altered at some later point in time. It took the automotive industry six years or more to design a new car, and in the 1990s, that time was cut almost in half.In an extreme but by no means unusual example, the Space Shuttle program, which operationally launched in 1982, used information and processing technologies from the 1960s. Highly complicated hardware and software systems were often designed, developed, and deployed in a time frame that spanned decades.In 2001, seventeen software developers met at a resort in Snowbird, Utah to discuss the lightweight development methods (Scrum, XP, DSDM, RAD, FDD etc.) among others Jeff Sutherland, Ken Schwaber, Jim Highsmith, Alistair Cockburn, and Bob Martin. Together they published the Manifesto for Agile Software Development, giving birth to an umbrella term “AGILE”.2) AGILE GIVES SPEEDY PROFITThere is no shortcut to success. Yes, shortcuts often lead to a quick upward trend in the management graphs but it falls sharply. Talking about Agile, there is NO shortcut. Sounds funny, but it’s true.Transformation is a continuous process of learning and change. Though transformation to Agile can deliver enormous benefits, the truth is that the majority of transformations go through spikes and dwindles in the chart. There is a tremendous effort that goes into training, team formation, not to mention - Forming, Storming, Norming, and Performing.While everyone is trying to adapt to this new change, the delivery capability can actually go downwards before it makes the step-change upwards and begins to achieve the improved delivery capability.3) BLAMING AGILE IF YOU TRIED IT ONCE AND FAILEDOne should always remember that Agile is NOT a magic wand that can solve all your problems. Any project may succeed or fail, even if you have adopted Agile.If something is not working out, try to retrospect and see what went wrong rather than blaming the process – how effectively it is used depends on decision-makers, not on the approach itself!!4) THERE IS AN EXACT SIZE OF THE USER STORYAs it goes for projects, in the same way, no two teams are the same. They have their own thought process and way of understanding the complexity, effort, and uncertainty.There isn’t a general accurate size for a User Story. It depends on the team, their skills, and their level of domain knowledge.So, one has to get over this notion that there is an exact size. NO, nothing as such exists.The size of a story depends on the experience and knowledge of a development team. When the team is new and in want of domain familiarity, they request more and more detail. Contrariwise, team members with experience and knowledge in the domain might not look at it that way.A user story can be the size of a skateboard or it can as big as a space shuttle.5) NON-FLEXIBILITY FOR FIXED DEADLINE PROJECTS IN AGILEAgile is most suitable for fixed deadline projects.  Surprised!!Well, yes, when you use Agile, particularly Scrum, you will notice there is something called time-boxing.Scrum just loves deadlines!!The team gets much of their control from the attaching deadline effects: sizing work to the deadline, individual commitment, and inclination to renegotiate just what is being built to meet a date.You can set your milestones in terms of sprint and can predict the release date too. Even your customer would be thankful for the vision of delivery you provided.6) AGILE ONLY RELATES TO SOFTWARE DELIVERYDuring one of my sessions last month, I came across a statement where the group thought that Agile is only for the Software industry and it can solve problems and provide a solution. And yes, it is one of the widespread notion or myth lingering since long.But, it’s NOT true.Even before the birth of the term “Agile” in the industry, we had Toyota (1953) working on the concept of Kanban, to deliver their products. Kanban comes under one of the umbrella items of Agile.We can see Agile being used in farming to increase the throughput. With the influx of real-time data and improved equipment that can act quickly, farmers can continue to make adjustments and iterate on their growing process throughout the season. One large iteration cycle (a growing season) can now be broken down into multiple mini-iteration cycles. Machine learning and analytics will shorten the time gap to translate data inputs into actions that get smarter over time.7) NON-FUNCTIONAL REQUIREMENT CAN BE DEALT WITH AT THE ENDDuring the days of waterfall methodology, non-functional Requirements (NFR) testing was generally the last step before application delivery.Now with the adoption of Agile, the application is built incrementally over multiple sprints which results in overcoming agile challenges and building better results.It is a ploy if the team is pushing it back to the end as the changes caused by incomplete/inadequately developed NFRs are potential large fixes, requiring costly architectural or design corrections.8) THINKING AGILE IS A SILVER GUNSHOT THAT WILL RESOLVE ALL YOUR SNAGSAs mentioned above, in point no. 3, Agile is not a magic wand that can address all the problems. You can fail just as dramatically on an agile project as you can using any other traditional method. But the catch is, that you fail early (acknowledgements to transparency and visibility)It is not going to solve your problems, but, it can surely empower you with the principles and values, which can help you achieve success. And it lets you know how to avoid mistakes in Agile. Now it’s up to you, how you want to adopt it – Just for the buzzword OR for real agility.CONCLUSIONAgile isn’t “just do it” – there are significant planning and re-planning involved when required.As you can see, these 8 common pitfalls in Agile can cause substantial blockers for anyone trying to implement Agile. But as long as you recognize this by keeping the above information in mind, your chances of getting better results with Agile will considerably improve.To end with, what do you think, are you Agile?
Rated 4.5/5 based on 1 customer reviews
Miscalculating Agile: Would You Choose Facts Or Opinions?
Blogs
374
Miscalculating Agile: Would You Choose Facts Or Op...

As rightly it’s been quoted “Easier said than ... Read More