Search

5 Reasons To Have Fixed-Length Sprints

Should the sprint length in Scrum be fixed or variable? It has been a hot topic of discussion for years but most of the experiences shared by Scrum Masters go in favour of fixed length sprints; and, I too follow the rule of fixed length sprints. According to Agile Cadences and Technical Debt Survey report, 68% Scrum Masters favoured fixed length sprints while 29% accepted to make infrequent changes in the sprint length. Only 7% Scrum Masters accepted to change sprint length frequently as and when required. No doubt, flexible sprint length releases work pressure on the members but this practice develops a number of undesired apparent or hidden snags pertaining to quality, cost, time and scope.  Here in this article, I will explore 5 more commonly accepted reasons to adopt fixed-length sprints framework.  1. Teams Benefits from a Regular Rhythm Regular time-boxed delivery is the core Scrum discipline; therefore, we can’t take the liberty to have flexible sprint lengths. In case of flexible sprint lengths, team members are unsure of schedule. The fixed duration sprint benefits the Scrum teams because each member has to be settled with a rhythm.   2. Sprint Planning Becomes Easier The fixed sprint length makes the sprint planning easier because the team members know how much work they are supposed to deliver in the forthcoming sprint.  3. Tracking Velocity Is Easier Tracking Scrum velocity is easier with same length sprints. You can’t be sure of completing twice the amount of work if the one-week sprint period is extended up to two weeks. The alternative practice may be to normalize the velocity on per-week basis, but it seems a needless and complex exercise if the Scrum sprints are kept at the same length.   4. On the Time Course Corrections It is very common to find a gap between the demand of the product manager and the amount of work delivered. Fixed-length sprints minimize that gap by bringing the product manager and engineers together at a fixed interval. The findings at each sprint guide the Scrum team to incorporate the required changes before the particular task is done, tested & documented.  5. Maximizes Responsiveness to Customer Fixed-length sprints improve the responsiveness to customer requests. True, instant turnaround to customer requests is not possible; yet, it can be addressed quickly at priority. The only way to satisfying the customer at the best is to deliver the new feature or to fix the bug quickly in short fixed-length sprint cycles.  How to Fix the Ideal Sprint Length – 5 Tips:   Ideally, sprint is a fixed time period of 1-4 weeks; it depends upon the team to schedule the sprint. The shorter Sprints spanned for one - two weeks help the Scrum teams identify the problems faster; but sometimes it seems uncomfortable. Many times, Scrum teams decide for the 3 - 4 weeks longer sprints to avoid indulgence towards these problems/ impediments; however, it is not a Scrum-like approach because Scrum principles guide to identify and deal with the problems at the earliest. So, the question is how to fix the ideal sprint length holding the balance between focus and opportunistic adaptiveness. The following 5 tips will help you optimize the sprints schedule:    1. Uncertainty may come in a variety of forms like not properly defined requirements, new technology, high-risk potential, difficult-to-implement interface etc. In case of significant uncertainty, you should go for shorter sprints - the most effective way to refine the project requirements or to try the new technology before getting set for solution development.  2. The volume of tasks and the expected time required affect the selection of sprint length. The team members should be comfortable to accomplish the task to complete a user story during the gap between the two sprints; and, as a Scrum Master, you should have a fair idea of the time required.     3. If you are facing a lot of disruptions, shorten the Sprint length to match the occurrence of disruptions.   4. The project duration is the key deciding factor for Scrum sprint duration. A short-period project such as one of three-month benefits from shorter sprints because of more reviews at shorter periods. If the project is long in duration, continue to look at the other factors. 5. Each Scrum sprint provides an opportunity to the Scrum Master to document the progress to stakeholders. Each sprint provides an opportunity to stakeholders to request for revisions. If you expect the stakeholders to provide input, prefer to set shorter periods for the sprints.   Setting your iterations too short in #scrum can have a damaging effect. "Failed" sprints and poor morale. #agile #teams — John Cutler (@johncutlefish) June 10, 2017 Concluding Thoughts:  Shorter Sprints are preferred because of many reasons as discussed above but these need to be scheduled perfectly at comfortable intervals so that the sprint planning, sprint reviewing, sprint retrospective can be meaningful. Instead of fixing the sprint length to fit the ‘Product Backlog Items’ size, it is better to make the items smaller. The Certifications like CSM and other project management training and courses provide the deep insights into the perfect sprint planning.  
Rated 4.0/5 based on 43 customer reviews

5 Reasons To Have Fixed-Length Sprints

234
5 Reasons To Have Fixed-Length Sprints

Should the sprint length in Scrum be fixed or variable? It has been a hot topic of discussion for years but most of the experiences shared by Scrum Masters go in favour of fixed length sprints; and, I too follow the rule of fixed length sprints. According to Agile Cadences and Technical Debt Survey report, 68% Scrum Masters favoured fixed length sprints while 29% accepted to make infrequent changes in the sprint length. Only 7% Scrum Masters accepted to change sprint length frequently as and when required. No doubt, flexible sprint length releases work pressure on the members but this practice develops a number of undesired apparent or hidden snags pertaining to quality, cost, time and scope. 

Cost, Scope, Quality & Time in Scrum

Here in this article, I will explore 5 more commonly accepted reasons to adopt fixed-length sprints framework. 

1. Teams Benefits from a Regular Rhythm

Regular time-boxed delivery is the core Scrum discipline; therefore, we can’t take the liberty to have flexible sprint lengths. In case of flexible sprint lengths, team members are unsure of schedule. The fixed duration sprint benefits the Scrum teams because each member has to be settled with a rhythm.  

2. Sprint Planning Becomes Easier

The fixed sprint length makes the sprint planning easier because the team members know how much work they are supposed to deliver in the forthcoming sprint. 

3. Tracking Velocity Is Easier

Tracking Scrum velocity is easier with same length sprints. You can’t be sure of completing twice the amount of work if the one-week sprint period is extended up to two weeks. The alternative practice may be to normalize the velocity on per-week basis, but it seems a needless and complex exercise if the Scrum sprints are kept at the same length.  

4. On the Time Course Corrections

It is very common to find a gap between the demand of the product manager and the amount of work delivered. Fixed-length sprints minimize that gap by bringing the product manager and engineers together at a fixed interval. The findings at each sprint guide the Scrum team to incorporate the required changes before the particular task is done, tested & documented. 

5. Maximizes Responsiveness to Customer

Fixed-length sprints improve the responsiveness to customer requests. True, instant turnaround to customer requests is not possible; yet, it can be addressed quickly at priority. The only way to satisfying the customer at the best is to deliver the new feature or to fix the bug quickly in short fixed-length sprint cycles. 

Reasons to have fixed length sprints

How to Fix the Ideal Sprint Length – 5 Tips:  

Ideally, sprint is a fixed time period of 1-4 weeks; it depends upon the team to schedule the sprint. The shorter Sprints spanned for one - two weeks help the Scrum teams identify the problems faster; but sometimes it seems uncomfortable. Many times, Scrum teams decide for the 3 - 4 weeks longer sprints to avoid indulgence towards these problems/ impediments; however, it is not a Scrum-like approach because Scrum principles guide to identify and deal with the problems at the earliest. So, the question is how to fix the ideal sprint length holding the balance between focus and opportunistic adaptiveness. The following 5 tips will help you optimize the sprints schedule:   

1. Uncertainty may come in a variety of forms like not properly defined requirements, new technology, high-risk potential, difficult-to-implement interface etc. In case of significant uncertainty, you should go for shorter sprints - the most effective way to refine the project requirements or to try the new technology before getting set for solution development. 

2. The volume of tasks and the expected time required affect the selection of sprint length. The team members should be comfortable to accomplish the task to complete a user story during the gap between the two sprints; and, as a Scrum Master, you should have a fair idea of the time required.    

3. If you are facing a lot of disruptions, shorten the Sprint length to match the occurrence of disruptions.  

4. The project duration is the key deciding factor for Scrum sprint duration. A short-period project such as one of three-month benefits from shorter sprints because of more reviews at shorter periods. If the project is long in duration, continue to look at the other factors.

5. Each Scrum sprint provides an opportunity to the Scrum Master to document the progress to stakeholders. Each sprint provides an opportunity to stakeholders to request for revisions. If you expect the stakeholders to provide input, prefer to set shorter periods for the sprints.

 


Concluding Thoughts: 

Shorter Sprints are preferred because of many reasons as discussed above but these need to be scheduled perfectly at comfortable intervals so that the sprint planning, sprint reviewing, sprint retrospective can be meaningful. Instead of fixing the sprint length to fit the ‘Product Backlog Items’ size, it is better to make the items smaller. The Certifications like CSM and other project management training and courses provide the deep insights into the perfect sprint planning.  

Shubhranshu

Shubhranshu Agarwal

Blog Author

Shubhranshu Agarwal is a technical writer with special interest in business management and project management subjects. Over the 15 years of freelance content writing, he has written a lot to help the industries, businesses and project managers to achieve the sustainable growth by implementing strategic critical management methodologies.
 

Leave a Reply

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

Suggested Blogs

Continuous Learning in Scrum – How to Conduct Powerful Retrospectives?

Scrum is an empirical process – as a part of the journey to become self-organized, the team goes through transitions as they face challenges to implement meaningful software that creates value for the end user. Retrospectives are a key instrument to trigger actions and the ideal catalyst of a changing behavior. Therefore, placing particular emphasis on conducting powerful retrospectives goes a long way and will change the face of the product in the long run.What is a retrospective?A retrospective is conducted by the Scrum team at the end of an iteration reflecting on how well the team worked together and what problems influence the performance of the team members. Retrospectives are a safe forum for teams to openly discuss and help to facilitate change. It is advised to keep iterations short (2 weeks ideally), especially when a new team is forming.Longer iterations of 4 weeks, for example, result in retrospectives carried out only once a month, which can prove to be dangerous. Changes do not frequently happen within the team when in fact it is needed as a result of a sub-optimal process being dragged along for weeks.How to run an Agile retrospective meeting?A popular technique is the “5 steps of a retrospective”, which defines a guide for valuable Agile retrospectives and how to facilitate team gatherings to discuss its way of working and to identify actionable items how to work more efficiently in the future. let’s see various Agile retrospective techniques below.1) Setting the stageDon’t jump right in but let people “warm up”. When working with teams I really like to use an exercise before the actual gathering of data about what went well and wrong.Ask 3 questions picking subjects that are “hot” matters within the team for instance and do pairings of 2. In rounds of 3 minutes, people get to discuss those topics and align with each other to formulate opinions and exchange thoughts. This is a perfect way to prepare everyone for step 2 where the actual way of working is inspected.2) Gather dataThis is where the magic happens. Time to talk about the details and surface the problems that the team is struggling with. There are hundreds of methods existing on how to structure a retrospective and produce valuable results. The quintessence is to find out what method is fitting the team’s circumstances. It is not a one size fits all.A general approach - discuss what works well and what doesn’tA popular method is the sailboat method.The wind that pushes the boat forward stands for items that help the team to perform well.The anchors are things that drag the team down and hinder them from achieving their goals.This is a great method to do a health check on the team. What’s important is that not only the negative aspects are talked about but that those aspects that really drive the team forward are put into consideration.Formulating a direct goalNot all retrospectives have to be rigorously focused on only talking about what went well and what went wrong in the past sprint. If they do indeed it may create the risk that the same items come up and are discussed over and over again.Let’s say for instance that there will be someone new joining the team in order to support on development. The direct goal would be to onboard the new team member efficiently.What you can use here is a method called “Success Criteria”. This exercise revolves around clarifying intentions, target outcomes and results for success criteria.As the name suggests you plan for the actual success of a goal but you also try to anticipate how a failure scenario may look like. In our example, the activity would structure in the following steps to take.Intention: We would like to onboard a new member of the team.Target: New team member is well connected with the team, knows the infrastructure, the tools the team works with, the product scope, the roadmap going forward and practices pair programming in order to learn and broaden expertise.Successful if: The new team member can independently work on backlog items and deliver customer-oriented features.Failure if: Within the sprint, a good portion of the time is spent to help the new team member work efficiently on the items.Summarized, this method helps the team align on upcoming processes that need to be handled in order to be fully focused on the product delivery process and plan ahead.3) Generating insightsAfter gathering the data it’s crunch time and bringing the outpouring of ideas, problems, and opportunities into a digestible format where actionable items can be produced from.A popular technique is to use Affinity Mapping to cluster and bundle facts and ideas together.You start out by taking one post-it and make it the first post-it in the first group.Another post-it is picked up and the facilitator asks if this is similar to the first one or if it differs. Following that, you will place it in the first group or into a newly-formed group.Once the participants have clustered everything into groups you continue to discuss the most important items from the different clusters.It is now time to attach names to the clusters in order to help you make the information more meaningful and point out various themes.You now have a mutual understanding of the biggest problems the team is facing.4) Decide What To DoIn this step, you produce the actionable items you will focus on. By using Affinity Mapping we have identified patterns and attached names to the different clusters.It is now time to decide what to do. This can be accomplished by using the method “Start, Stop and Continue” originally introduced by Esther Derby and Diana Larsen in their book “Agile Retrospectives: Making Good Teams Great (Pragmatic Programmers) and enhance it with a dot voting system.You draw three sections with the headings start, stop and continue.We now place our clusters into those three sections.Following we use a dot voting giving each person three votes to vote on those items most important to them. Votes can either be cast on a single item or distributed across multiple.Pick the ones with the most votes. Try to really focus on what impacts the team the most. It is a good idea to reflect on actual feasibility and what can be accomplished short and long-term before coming to a decision on the items. Based on the size and scope of clusters it also makes sense to not go for too many action items. A Top 3 is reasonable.5) ClosingThe closing is often underestimated and the group dissolves after the action items are clear. Reflect on what you have just achieved.Use the “Takeaways” method (Judith Andresen – book “Erfolgreiche Retrospektiven”) and ask everyone to write a note to reflect on the one thing that was outstanding for them in this retro. Each participant then reads out their own note to the group.Alternatively, use the “Retro dart” method (introduced by Philipp Flenker) to end on a high note. This is a little retro inside a retro.You draw several dartboards and write a question next to the board (see image above). The participants then add post-its to the dartboard. 100% agreement is right in the middle and 0% outside the disc.For further inspiration, check out Philipp Roger’s trello boardSummaryFor a scrum team to be successful it is essential to conduct effective retrospectives to review their way of working and align their processes. It matters what method is used to improve a process or overcome a problem and which idea you use to improve your Scrum Retrospective. After all the product benefits from this and actions defined in a retro will increase the time to market. So, next time you think about skipping a retro, don’t because it may influence your product delivery.
Rated 4.0/5 based on 1 customer reviews
Continuous Learning in Scrum – How to Conduct Po...

Scrum is an empirical process – as a part of the... Read More

Decision About Which Agile Method To Use - A Perspective

Introduction:Agile methods have gained widespread acceptance in software development organizations for formulation and development of solutions for enhancing existing products or creating new ones. The method has been very effective in the continuous delivery of new and effective solutions.Organizations trying to introduce Agile methodologies, in the beginning, are faced with a choice of which type of Agile methodology is best suited for their environment and types of project work. You may learn more about the challenges encountered by the first-time Agile organizations here.The Agile Manifesto favors the delivery of working software in comparison to comprehensive documentation. There is a constant emphasis on a relation between organization and developers rooted in-Trust,Integrity, andTransparency.It may not be a huge shift, but is still a powerful challenge for many companies. The team should be trained well, should be aware of Agile concepts and should have the required tools needed to perform. A team of experienced and skilled developers is more efficient to take decisions when compared to a less experienced team and understands customer commitment much better. Agile delivery values direct interaction and business user collaboration instead of uneven communication in the life cycle  at fixed points. Effective involvement of the  business reduces the delivered features risk that do not meet customer requirements.How to decide the best Agile methodology that is suitable for an organization?Despite the fact that every Agile methodology offers incremental and iterative delivery of software, the differences lie in the way artifacts produced and each methodology is executed.Let us discuss in detail the most popular Agile Methodologies:Scrum: Scrum is focused on self-organizing teams. Its core principles are aligned with client-driven adaptive planning. Scrum method’s main priority is the delivery of working software in no more than 30 days. Delivered software needs to be in releasable shape.Minimum documentation is supported. Scrum is most used in the Agile framework. Its widespread usage and benefits have made it the most popular Agile method.Extreme Programming(XP): It keeps things simple and concentrates on the continuous implementation of best practices such as-Ongoing testingRefactoringCode reviews (pair programming)Continuous integration.In this method, there is a focus on the developer’s capability and getting into the development of the working prototype as fast as possible.Feature Driven Development (FDD): Breaks down the delivery of a larger product into small features. Typically, FDD is characterised by-Short iteration cyclesSimple processesSuitability for predictable evolutionThe method needs experienced resources to define the required features in great details to make them implementable.Kanban: It is based on Toyota’s just-in-time (JIT) production system. The salient features are as follows-Focuses on eliminating bottlenecksIncredibly simple and powerful Kanban boardsKanban uses Flow and visual methods to bring elements of agile in the overall development process.Makes elaborate use of visual tools.Typical usage involves a space in the office area with printed boards showing status of the activities as shown in the diagram below.Lean Development: Lean Development concentrates on offering value for money. It recommends amplifying learning, avoiding unnecessary errors, delivering as early as possible and deciding as late as possible. The first and foremost principle of lean project management is diminishing waste in an established process. It is more frequently applied to production and manufacturing than in product development. Lean mainly focuses on key process improvement points, such as standardizing means of production and reducing bottlenecks. Although Lean has a different application than the Agile methodology, there are certain common elements such as-Valuing a strong facilitator andPipeliningDSDM: It is developed from a business perspective and lays a strong emphasis on project management. The plans produce based on increments.Sometimes, a combination of multiple methods is the best solution. For example, a combination of Scrum and Kanban is a preferred combination for projects that need the iterative approach of Scrum and the visual elements of Kanban. Similarly, pair programming aspects of Extreme programming (XP) are borrowed for Scrum development teams. It is also advisable that, Agile is not a suitable methodology for some projects. This also should be kept in mind while evaluating an appropriate Agile methodology.In Summary:Agile method to be used for an organization depends on the objectives and desired outcomes. The methods can be implemented either in an existing program or for a new one. Current state and resources available will be of prime importance in deciding the approach and the timeline of implementation. It has been proven time and again that Agile methodologies help an organization to improve the speed of product delivery and quality. They also help establish clear communication channels within the organization and with critical customers and have an approach and method to incorporate customer feedback quickly in the product roadmap.
Rated 4.0/5 based on 0 customer reviews
Decision About Which Agile Method To Use - A Persp...

Introduction:Agile methods have gained widespread ... Read More

Scrum Master vs. Project Manager: Differences and Similarities

Organizations that are new to Agile and Scrum commit some deadly blunders. The most common and overlooked one is the lack of clarity of the roles of the Scrum Master and the Project Manager. This is more often seen in smaller Scrum teams, where these two discrete roles overlap.  There are of course similarities between Scrum Master and Project Manager roles. But that does not give way to ignoring the distinct differences between an Agile Project Manager and Scrum Master.  We have spaced out this article into various sections-    Scrum Master vs. Project Manager roles and responsibilities Scrum Master roles and responsibilities: Scrum Master is referred as a facilitator, who manages the teams that are implementing the Agile methodology. Scrum framework is the best framework for smaller teams of developers, who can break their work into a Sprint in order to get your project done at the end of every sprint.  The roles and responsibilities of the Scrum Master includes- Sprint planning  Scheduling the daily Scrum meeting Managing Scrum process responsibly Helping the Scrum teams to follow Scrum practices Removing barriers so the team can focus on their work Assisting with the Product Backlog Co-operating with Product Owner in designing Product Backlog items for the next Sprint Protecting the team from external distractions Recording and assisting to improve team dynamics   *Project Manager roles and responsibilities: Project manager’s role is to manage the projects and ensure that the project meets the requirements. The roles and responsibilities of the Project Manager are as follows- Defining project scope to the team Planning project target Preparing the work schedule for the team members Gathering requirements Defining the resource requirements for the project Preparing the budget for a project Assuring quality Mitigating the risks Monitoring the plans Getting user feedback Managing relationships with the client and the stakeholders Ending the project   Similarities between the Scrum Master and the Project Manager Project Manager and Scrum Master both are humans and they both make mistakes. But they both debug and learn from the mistakes. They both can communicate, receive feedback, mitigate the risks, and enable a great bonding within a team. Actually, neither the Project Manager nor the Scrum Master is the supreme authority. The Project Manager has to report to the client and the stakeholders, whereas the Scrum Master has to report to the Product Owner alongside the stakeholders and clients. Both Project Manager and the Scrum Master fail when they ignore the basic principles that are supposed to be adhered to. They fail when they not only neglect being professionals, but also when they are any less than skilled professionals. Sometimes, they may also fail when they disrespect the team members’ opinions. Differences between the Agile Project manager and Scrum Master While noting down the differences between the Project Manager and the Scrum Master, you will find out that the Project Manager plays the leadership role by leading a planning for the execution of the project. Scrum Master plays a support role for the team members, by working closely with the team and assuring that they are following Agile principles properly. Let’s look at the major differences between the PM and SM: Project Manager(PM) vs.Scrum Master(SM) Goals Has defined goals like- Completing the project on time, planned budget, and scope Makes sure that the team members are well trained to follow Agile practices appropriately. Also, SM coaches the Scrum teams and mentions the timeline to finish the project. Quality Assurance PM also knows the importance of quality, but doesn’t know how to achieve this. Usually, a consultant is hired to fix the errors. SM assures the quality and very well knows the importance of it. Team Size Project Managers like to make the things large. PM works with more people and a huge budget. In this way, they improve to Program Manager Scrum Master always tries to keep things smaller. They like to work in small teams irrespective of budget. Average Salary Rs.1,351,403 per year Rs 1,036,017 per year Job Description The job description of the Project Manager includes- Planning, creating budget and the related documents PM has to work with upper management to ensure a scope and direction of a project PM has to work with another department also, in case of emergency sometimes have to work themselves or instruct the team to finish a goal. The job description for Scrum Master includes- Resolves barriers and controls the Scrum processes. Making a team aware of Agile and Scrum to deliver successfully Facilitates the Scrum ceremonies Ensures that a project is running smoothly with the help of the tools Executes the Product Backlog as per the Product Owner prioritization Solves team conflicts with good communication skills Motivates the team Monitors the Scrum processes to increase efficiency   Scrum Master vs. Project Manager certification The Scrum Master and the Project Manager certifications are the two most popular certifications of the Agile and Waterfall methodologies.  Scrum.org report as of 30th April 2017 states that around 110,000+ people are  Scrum certified. Only 56% of the Project Management Specialists are holding a Project Manager Certificate, even in Big IT companies. This was revealed in a survey conducted by IBM.    Last words: Deciding between the Scrum Master and Project Manager certification is indeed a tough choice and entails a careful consideration of the prospects of each. Eventually, the role of a Scrum Master is proved as a ‘deciding factor’ of the successful projects. The Scrum Master and the Project Manager both have distinct roles. Both need particular skill-sets and a right person to make the work happen.       
Rated 4.0/5 based on 9 customer reviews
1244
Scrum Master vs. Project Manager: Differences and ...

Organizations that are new to Agile and Scrum comm... Read More

other Blogs