top
Sort by :

Are You Delivering Potentially Shippable Product Each Sprint?

By the end of each iteration, a Scrum team is expected to produce a Potentially Shippable Product. As we know Agile methodologies emphasizes on “Working Software over Comprehensive Documentation”. When we talk about working software, it is both complete and potentially shippable. Agile methodologies emphasizes on working software which is both complete and potentially shippable due to following 3 reasons: It encourages feedback It helps a team gauge it’s progress It allows the product to ship early if desired In order to ensure, we are delivering a Potentially Shippable product at the end of the sprint, we must understand what potentially shippable means. Defining Potentially Shippable As per Scrum Inc, a Potentially Shippable Product is the outcome of the Product Backlog Items delivered at each Sprint. Delivering Potentially Shippable Product at each Sprint is essential to the Scrum because when work is divided into simple pieces it can be finished in a short iterations. As per Mike Cohn, "potentially shippable" and "shippable" are not the same thing. Some large or complex projects will require the use of "release sprint" or "hardening sprint" at the end of a release cycle (say 6 two-week sprints then a 2-week release sprint). The release sprint is not a dumping ground for sloppy work; rather it is a place where some hardening of the system can occur. Let’s have a look at some of the guidelines here: Organizations define their own ‘definition of done’ for every product and project. However, there are some guidelines that are applicable for almost all the Scrum projects in most of the organizations. Potentially Shippable means Tested! There can be no situation where a product is delivered without being tested. By the end of the Sprint, the delivered product increment needs to be bug free. If needed by the Product Owner, the feature should be a bug free, it can be released to the beta users or the stakeholders to review. Potentially shippable does not mean cohesive Just because we know that the product is potentially shippable, this doesn’t mean that people wants us to actually ship it. Many times it takes 2, 3 or more sprints for a feature set to come together to be useful. However, during the Sprints leading up to that point, the team should still strive for a product to be potentially shippable. The #Scrum team as a whole is responsible for delivering a working increment of the product at the end of each sprint http://t.co/NqnOc7JeUt — Manifesto (@ManifestoLondon) September 16, 2014 Potentially shippable means integrated A potentially shippable product doesn’t exist as different collections of source code. On a project, where multiple teams are working, the teams should define the statement of done such that it includes integrating development steams. So, Integration should be done continuously throughout the sprint. Does Potentially Shippable means Shippable? Well, when we define the ‘definition of Done’, We want it to be a Potentially Shippable product. This doesn’t mean that it has to be shippable. Whether the product needs to be shipped or not, that’s a decision taken by the Product Owners, or Business Owners.  Hence, Potentially shippable is a state of confidence, that the product delivered at the end of the Sprint, is so Done that it’s Potentially Shippable.
Are You Delivering Potentially Shippable Product Each Sprint?
Ridhi
Rated /5 based on 12 customer reviews
Ridhi

Ridhi Chhabra

Blog author

Ridhi Chhabra is working in the field of Project Management from last 8 years. She is also a Certified Scrum Master (CSM). She has been implementing Scrum Framework in 80% of her projects which are resulting in Successful Project Completion and Great Customer Experience. She has great Communication skills and got a proven experience in interacting with customers around the globe, across US, UK, Australia and South Africa.
She is currently working as an Executive Assistant Project Manager at KOHLEX Design India Pvt. Ltd., It is US Based Organization which is having main headquarters in California, United States and is handling operations in Hyderabad, India.


She enjoys meeting new people, traveling and writing blogs and articles. Refer to her LinkedIn for more articles.

Are You Delivering Potentially Shippable Product Each Sprint?

By the end of each iteration, a Scrum team is expected to produce a Potentially Shippable Product. As we know Agile methodologies emphasizes on “Working Software over Comprehensive Documentation”. When we talk about working software, it is both complete and potentially shippable. Agile methodologies emphasizes on working software which is both complete and potentially shippable due to following 3 reasons: It encourages feedback It helps a team gauge it’s progress It allows the product to ship early if desired In order to ensure, we are delivering a Potentially Shippable product at the end of the sprint, we must understand what potentially shippable means. Defining Potentially Shippable As per Scrum Inc, a Potentially Shippable Product is the outcome of the Product Backlog Items delivered at each Sprint. Delivering Potentially Shippable Product at each Sprint is essential to the Scrum because when work is divided into simple pieces it can be finished in a short iterations. As per Mike Cohn, "potentially shippable" and "shippable" are not the same thing. Some large or complex projects will require the use of "release sprint" or "hardening sprint" at the end of a release cycle (say 6 two-week sprints then a 2-week release sprint). The release sprint is not a dumping ground for sloppy work; rather it is a place where some hardening of the system can occur. Let’s have a look at some of the guidelines here: Organizations define their own ‘definition of done’ for every product and project. However, there are some guidelines that are applicable for almost all the Scrum projects in most of the organizations. Potentially Shippable means Tested! There can be no situation where a product is delivered without being tested. By the end of the Sprint, the delivered product increment needs to be bug free. If needed by the Product Owner, the feature should be a bug free, it can be released to the beta users or the stakeholders to review. Potentially shippable does not mean cohesive Just because we know that the product is potentially shippable, this doesn’t mean that people wants us to actually ship it. Many times it takes 2, 3 or more sprints for a feature set to come together to be useful. However, during the Sprints leading up to that point, the team should still strive for a product to be potentially shippable. The #Scrum team as a whole is responsible for delivering a working increment of the product at the end of each sprint http://t.co/NqnOc7JeUt — Manifesto (@ManifestoLondon) September 16, 2014 Potentially shippable means integrated A potentially shippable product doesn’t exist as different collections of source code. On a project, where multiple teams are working, the teams should define the statement of done such that it includes integrating development steams. So, Integration should be done continuously throughout the sprint. Does Potentially Shippable means Shippable? Well, when we define the ‘definition of Done’, We want it to be a Potentially Shippable product. This doesn’t mean that it has to be shippable. Whether the product needs to be shipped or not, that’s a decision taken by the Product Owners, or Business Owners.  Hence, Potentially shippable is a state of confidence, that the product delivered at the end of the Sprint, is so Done that it’s Potentially Shippable.
Are You Delivering Potentially Shippable Product Each Sprint?
Author Image
Rated /5 based on 12 customer reviews
Are You Delivering Potentially Shippable Product Each Sprint?

Are You Delivering Potentially Shippable Product Each Sprint?

122 76 Agile Management
Ridhi Chhabra
By the end of each iteration, a Scrum team is expected to produce a Potentially Shippable Product. As we know Agile methodologies emphasizes on “Working Software over Comprehensive Documentation...
Continue reading

Patterns For Adopting & Spreading Scrum In Organizations

When we talk about adopting any new framework or methodology, we think about how we can incorporate these changes into our organization. We simply cannot impose any change in our organization and get started with it, there has to be some process or ways to incorporate that. Also, there are some ways to incorporate Scrum changes within our organization. There include five activities in adopting the Scrum successfully: Awareness Desire Ability Promotion Transfer So to remember, we call it by the acronym ADAPT.  Let’s now talk about the Patterns of Adopting and Spreading a Scrum: Patterns for Adopting Scrum   Start Small or Go All In Organizations go ahead with it like a Pilot project, like selecting few team members and implementing Scrum with them, It's a ‘Start Small’ pattern. The other approach can be Go All In, which is like the executives are convinced and want the whole organization to implement in one go. Reasons to prefer starting small It’s less expensive Early success guaranteed Avoids risks of going all in Less stressful Can be done without much change Reasons to prefer going all in Reduces resistance Avoids problems within different teams The All-in transition is Quick! Choosing between the two  As recommended by Mike Cohn, one should always Start Small! It involves less cost, and guaranteed early success. Going all in should be in limited cases, only when it’s a quick need. Also, it involves more cost/money as there are a lot of changes in different departments if required. Public Display of Agility or Stealth The next pattern that comes into the picture is whether to Publicize it or not. We can do the Public Display of Agility. In this approach, the organization announces that it is adopting Scrum. This can vary from announcing it in a meeting room to announcing it through the press release. The other approach is Stealth transition. In this, only team members know they are using Scrum until the project is complete.  Reasons for Public Display of Agility Everyone knows that team is doing it and they are more likely to be focussed Operating publicly is a firm statement of commitment You can solicit organizational support It sends a powerful message Reasons for Stealth Transition A chance to make progress before resistance starts It keeps pressure off No one knows until you tell them If no one knows, no one can tell you to stop Choosing between the two As recommended by Mike Cohn, always choose to make a public display of Agility when you are confident and committed to the transition and when you expect a lot of resistance but want to overcome it quickly. In contrast, choose a quiet approach, when you want to do an experiment using Scrum.    Patterns of adoption: "Going Through the Scrum Motions as Opposed to Being an Agile Jedi " https://t.co/tpv9kIVxNU @MichaelNir (via @InfoQ) — Stefan Wolpers (@StefanW) May 16, 2016 Patterns for Spreading Scrum   Getting started with Scrum is one thing, spreading it across the organization is another. Unless you choose an all-in transition, you will need to build upon the successes of the first few teams as you move Scrum to other teams.  There are 3 general patterns given by Mike Cohn that talks about spreading Scrum. Split and Seed This talks about taking a team that has begun to be successful with Scrum and using its team members to seed new teams. It’s typically put to use after the first few teams have successfully implemented and adopted Scrum. By this time, each team member understands how Sprint work and how the ready software is delivered at the end of the sprint.  In Split and Seed pattern, we split one functioning Scrum team into each half of the original team forming the basis of the new team. New people are then added to these split teams to form new Scrum teams.  A large initial team is used to seed as many as four new teams. Collated below are the reasons to prefer Split and Seed pattern. Add teams more quickly Each team has someone with Scrum experience to guide them Grow and Split The Grow and Split pattern involve adding team members until the team is large enough that it can be comfortably split in two. Immediately after splitting, each of the new teams will probably be on the small end of the desirable size ranging five to nine members. After allowing the new teams one sprint at this reduced size, new members are added until each team becomes a large enough that it can also be split. This pattern repeats until the entire organization has transitioned. In following cases, you can prefer Grow and Split pattern. Don’t have to destroy any existing teams Team members feel more continuity from sprint to sprint Internal Coaching The Third pattern of Spreading Scrum is Internal Coaching. In the organizations, there include types of teams. Some teams excel with the new agile approach, while others struggles. On each team, there exists one identified person who understands and implement Scrum successfully. That person is assigned as a Coach for other teams. Coaches were given responsibilities to attend sprint meetings, daily scrum each week and coach other teams. Reasons to prefer Internal Coaching Well running teams do not need to be Split Coaches can be selected for new teams Coaches can move from team to team Choosing your Pattern! In general, consider going with Split and Seed pattern, when in a hurry. It is the fastest way of spreading Scrum. However, if the technology doesn’t support moving people among teams, changing the team members can affect the productivity.  The Grow and Split pattern is simply more natural and direct approach. Consider using this approach if there is no sense of urgency as it is less risky.  Internal Coaching can be used on its own, mostly when the group is large enough and when splitting teams are not possible for the projects.
Patterns For Adopting & Spreading Scrum In Organizations
Author Image
Rated /5 based on 13 customer reviews
Patterns For Adopting & Spreading Scrum In Organizations

Patterns For Adopting & Spreading Scrum In Organizations

114 67 Agile Management
Ridhi Chhabra
When we talk about adopting any new framework or methodology, we think about how we can incorporate these changes into our organization. We simply cannot impose any change in our organization and get ...
Continue reading

We’re in Agile, We don’t Plan! Really? 

‘We are in Agile, we don’t plan!’ This was one of the most common statements in early Agile implementations. Many people in early Agile implementations took this step, knowing that they were giving up something really valuable. However, there was a natural reaction to this. This is now considered as a common myth, as planning is a fundamental aspect of Scrum. The Scrum team is committed to working towards the working software delivery with the highest value. To implement this, the team and Product Owner must have an estimate of the feature, cost for development. Intelligibly, a Scrum team is committed to working according to prioritization. Hence, Planning is an essential practice! In fact, We Plan a Lot! Sprint starts with an event called Sprint Planning The next step in planning is when the Scrum team estimates and commits to working towards the delivery of potentially shippable product at the end of the Sprint. Scrum team comes up with a detailed plan of- How much are they estimating, that they will complete within the sprint? How much will be the cost/value/hours of the tasks to be delivered? Planning happens on an everyday basis The Daily Scrum for the Scrum Team is to review the progress and refine the plan to meet the Sprint Goal. Plan on what is to be done Plan on overcoming the impediments How successful is your sprint planning? https://t.co/PTyozdqh7L @kbondale looks at 4 common challenges which impact this critical ceremony #agile #pmot #sprintplanning pic.twitter.com/2xS9a0zC34 — Agile Alliance (@AgileAlliance) March 28, 2018 Scrum Teams Own the Plan In each event, we are “Inspecting and Adapting”, Scrum teams takes the Product Backlog and come up with their plan and create their own Sprint backlog. They create it, inspect it and then adapt it for upcoming sprints and better results. Sprint Review and Retrospectives are the part of the Plan The Sprint Review is a collaborative event where the whole team gathers, reviews the product increment created, comes up with a feedback and adapts to make changes. This all is to support the planning of the next Sprint. The Sprint Retrospective is again a collaborative event to enable and plan for continuous improvement. Team plans to start, stop and continue doing the things in the current process. Progressively Refine Plans The Product Backlog should be progressively refined. It should be broken down into small user stories which can be easily implemented as we move along with the project. Eventually, the similar approach is to be taken while planning in Scrum. Let’s have a look at the advantages of having a progressively refining a plan in Scrum- It minimizes the time investment:  Planning is important, but it can be time-consuming. The time spent in estimating and planning is best viewed as an investment.  It allows decisions to be made at an optimal time:  Progressively refining the plan helps the team avoid falling into the trap of making too many decisions at the outset of the project. It allows us to make course changes:  One thing we know, when we are in Agile, that change always happens. Planning enough that we know in general but not all the aspects leaves the team with the flexibility to alter the course as more is learned.  It helps us avoid falling into the trap of believing our plans:  No matter how well we understand the expectations, and that no plan is safe from change. Progressively refining a plan reinforces the idea that even the best plan is subject to change. So, when next time you say, We’re in Agile, We don’t plan! Really? Think about it! 
We’re in Agile, We don’t Plan! Really? 
Author Image
Rated /5 based on 1 customer reviews
We’re in Agile, We don’t Plan! Really? 

We’re in Agile, We don’t Plan! Really? 

115 69 Agile Management
Ridhi Chhabra
‘We are in Agile, we don’t plan!’ This was one of the most common statements in early Agile implementations. Many people in early Agile implementations took this step, knowing that t...
Continue reading

SUBSCRIBE TO OUR BLOG

Share Blog

View All Topics

Follow Us