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

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

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

Join the Discussion

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

Suggested Blogs

Scrum Master and Product Owner: Understanding the Differences

According to the State of Scrum report 2017-2018 based on the data collection initiated in 2013. This survey represents the real world implementations of Scrum.     Agile methodology imparts the easy and convenient path to work. Scrum is one of the renowned Agile methodologies. The agile methodology consists of 4 main roles, viz. Product Owner, Scrum Master, Scrum team and Stakeholder. Each role has its share of responsibilities. These roles are all about commitment.     Scrum Master and the Product Owner are the two vital roles in the Scrum software development methodology. Since they both are working on different areas of the project, they are indispensable for the project. Scrum Master is a mediator between the Product Owner (PO) and the Development Team.     Let’s see how a Scrum Master is different from a Product Owner. Difference between the Product Owner and Scrum Master-   Though the Product Owner and the Scrum master vary in their roles, they complement each other. Scrum master should support the Product Owner in every step possible. There should be an amicable relationship between the Product Owner and the Scrum master. Disputes may happen between them if the roles are not clarified. Let us have a look at the differences in roles between the Product Owner and the Scrum Master. The Scrum Master concentrates on the project success, by assisting the product owner and the team is using the right process for creating a successful target and establishing the Agile principles.     Skills of the Scrum Master (SM): Removes the impediments and keep the team on track The Scrum Master helps the team to strictly adhere to the Scrum practices and helps them in reaching the target. The Scrum Master find out the distractions that are hindering the team from delivering the product quality. The distractions include unwanted meetings, complexity in the procedure, work environment etc. Encourages Collaboration The Scrum Master notices the daily activities of the team members. Also, the SM share his/her experiences with the team members via meetings, conferences, and seminars. The Scrum Master encourages the collaboration through the stand-up meetings, the release of planning sessions, iteration planning, and demo sessions. Good listening and Communication power The Scrum Master should have good communication skills in order to discuss the ideas and plan with the team. Good communication helps to deliver messages to customers, teams, and target audiences. Also, listening to the team members will help them share their ideas with the Scrum Master. So, Scrum Master should be a good listener also. Mentors the team as a Coach A successful Scrum Master understands the importance of the team working in collaboration. He/She mentors the team members as a Coach to implement the Scrum practices.    Flexibility for adopting the change The Scrum Master should be flexible for adopting any change. While implementing the Agile methodology, the team members may face the problems. So, the Scrum Master should be able to help the team members to adopt the changes. The Scrum Master facilitates the daily Scrum meetings for the team members to discuss their issues that are hindering the project growth.     Partnership with the Product Owner Scrum consists of three roles – Product Owner, Scrum Team and Scrum Master. The Scrum Master acts as a mediator between the development team and the Product Owner. The two roles- Product Owner and Scrum Master are valuable for the team, as they build a perfect relation with the team and thereby delivering the best results. Servant Leadership quality The Scrum Master provides collaboration. Scrum Master is also known as a Servant Leader.  He/She guides the team members on how to follow the Scrum approach to motivate the team members to deliver the best. Responsibilities of the Scrum Master:   Scrum Master facilitates team for better vision and always tries to improve the efficiency of the teams. Scrum Master manages Scrum processes coordinating with the Scrum team in the Agile methodology. Scrum Master removes impediments for the Scrum team. Scrum Master arranges daily quick stand-up meetings to ensure quick inspection and proper use of adaptation processes. Scrum Master helps Product Owner to shape the product backlog and make it ready for the next sprint. Conducting retrospective meetings. Scrum Master organizes and facilitates the sprint planning meeting. Most importantly, the Scrum Master removes the impediments that hindering the project success. Scrum Master keeps the team away from the distractions. The Product Owner’s responsibility is to focus on product success, to build a product which works better for the users and the customers and to create a product which meets business requirements. The Product Owner can interact with the users and customers, Stakeholders, the Development team and the Scrum Master.   Skills of the Product Owner (PO): Product Owner should have an idea about the business value of the product and the customers’ demands. Certified Scrum Product Owner Certification (CSPO) will be beneficial for the sales team. The development team consults the Product Owner, so he should always be available for them to implement the features correctly. Product Owner should understand the program from the end-user point of view. Marketing is discussed on the sales level in most of the Organizations. So it is the Product Owner’s duty to guide the marketing persons to achieve the goals successfully. Product Owner is responsible for the product and the ways to flourish a business. Product Owner has to focus on the proper production and ROI as well. Product Owner should be able to solve the problems, completing trade-off analysis and making decisions about business deliverables. After Certified Scrum Product Owner course, Product Owner can work with the project managers and the technical leads to prioritize the scope for product development. Sometimes Product Owner and the Customers are same, sometimes Customers are thousands or millions of people. Some other skills are as follows: 1.Communication Skills Communication is the key factor for any team member to be successful.  The team should be open to working together to achieve a common project target. It is very important that everyone on the team should communicate effectively. Most probably, the Product Owner should possess good communication skills. As the Product Owner needs to work with the customers’ to understand their needs and conveying that to the development team to bring it to reality. If they could not able to communicate effectively, it may affect the organization value. 2.Commitment The Product Owner should be committed to the project target, product vision, team, and the business. They have to attend all the meetings and work with all the team members. So, it is very important for them to collaborate with everyone. Furthermore, the Product Owner must be accountable for the process and be committed to the success of the project 3. Vision The Product Owner should be able to clearly communicate the product vision between the backlog items and the large project goals. They check whether the product vision is aligned with the company’s vision and needs. 4.Curious about what they work Concerning that “bad product owner” is so often the excuse for bad product. I coach towards product leadership and team ownership. My worst case is product owner telling the team exactly what to build, and team not taking ownership of the outcome. That’s what “bad” looks like. https://t.co/Um4rgvJ7yk — Jeff Patton (@jeffpatton) April 4, 2018 The Product Owner (PO) need to be curious always to ask ‘Why’ from the client (about his/her requirements) and ‘How(to the development team). But before asking the questions to the team, they should understand the rules and able to create a clear vision of the final product. Responsibilities of the Product Owner: Product Owner has to attend the daily sprint planning meetings. Product Owner prioritizes the product features, so the development team can clearly understand them. Product Owner decides the deadlines for the project. Product Owner determines the release date and contents. Product Owner manages and creates the product backlog for implementation, which is nothing but the prioritized backlog of user stories. Product Owner defines user stories to the development team. Spending some time to prioritize the user stories with a few team members. The Product Owner and Scrum Master Relation     This question is highly debatable in an Agile world. Many say that there needs to be a clear contrast between these the Scrum Master and Product Owner and therefore needs two individuals to manage these two roles. The Product Owner should have an overall vision of the client’s requirements. Due to this reason, the Scrum Master needs the Product Owner. Whereas the project team requires the Scrum Master to work maintaining the velocity and capacity of the team. Choosing the best The Product Owner has to get involved in grabbing the project details. But, along with that, the Product Owners expect an experienced Scrum Master should work and guide his/her team members to work efficiently yielding good results. The Scrum Master and the Product Owner have mostly overlapping roles and responsibilities and skills as well. Every one of them requires an alternate level of communication and mindset.  
Rated 4.0/5 based on 1 customer reviews
6360
Scrum Master and Product Owner: Understanding the ...

According to the State of Scrum report 2017-2018 b... Read More

Writing Effective User Stories in JIRA

User stories are one of the main methods of communicating requirements to developers/development team in an Agile project. It is important for the individual tasked with documenting the requirements to be able to write effective and detailed enough user stories. The user stories are required to be comprehensive enough to enable the developer/development team to start analyzing, designing and developing the required functionality, feature or requirement stated in the user story.     This article while intending to guide individuals on how to write effective user stories is also intended to advise on the best practices of creating user stories using JIRA as a requirements management tool for creating stories and tasks. What is a User Story?   User stories are short, simple descriptions of a feature in the system under development told from the perspective of the person who desires this new capability. This person is normally a user of the system or even a customer who pays for the solution.  User stories typically follow a simple template as below. As a , I must be able to so that I can .  User stories are often written on index cards or sticky notes and pasted on an information radiator or in other words a scrum board. This article is however on maintaining user stories using JIRA and on how the tool can be used to ensure regular conversation.  Writing user stories on an index card is actually the ‘Card’ part of the 3 C’s in user stories. It is said that a user story should be long enough to fit into an index card and be detailed enough to arouse discussion. Writing user stories in JIRA A new user story in JIRA can be created by selecting the option to create a new issue of type ‘Story’ as shown below.  The user story in the format listed above can be written in the summary field of the new issue creation screen.  User story definition should satisfy the INVEST criteria which implies that the user stories should be: Independent (of all other user stories and be able to exist on its own) Negotiable (not a specific contract for features but be able to be used to facilitate discussion among relevant stakeholders) Valuable (create some business value) Estimable (to a good approximation) Small (so as to fit within an iteration) Testable (in principle, even if there isn’t a test for it yet)   Trace your Customer Requirements to user stories in Agile through the integration with JIRA. https://t.co/esXyAJykZy pic.twitter.com/DZoa1tJrjL — Visure Solutions (@VisureSolutions) 21 November 2017   JIRA also provides the option to set priority of user stories which might have been done based on the MoSCoW criteria, due dates, assign the story to a team member of the project, allocate a story point/hour based effort estimation for the story, tag the user story to a component level feature or in other words ‘Epic’ and be able to assign the story to a sprint during which the story is required to be implemented. Adding description to user stories The 2nd C of the 3 C’s in user stories that is ‘Confirmation’ is used to specify the acceptance criteria of the user story. An acceptance criterion is used to ascertain when a particular user story can be marked as done and is normally used by the product owner to validate the same. The acceptance criteria also help the development team implement the business rules, functionality and will be the single point of reference for the Quality Assurance Team. The description field in JIRA issue creation provides space for the user to specify the acceptance criteria.   Gearset’s Jira Self-hosted (on-prem) and Jira Cloud integration lets you automatically post deployment updates to your tickets & keep up-to-date with the progress of your user stories. https://t.co/qvDlNK5LLr pic.twitter.com/yh8RmUL1Gm — Gearset (@GearsetHQ) 29 January 2018 Enabling discussion Another main aspect of writing requirements as user stories is to enable conversation about the feature among relevant stakeholders. This is known as the ‘Conversation’ component of user stories which is the 3rd C in the 3C’s.  Often user stories are accompanied with a process diagram, UI wireframe or a mockup, data dictionary etc. which can be added as attachments in JIRA or even be associated with the story as comments, wiki page links maintained in confluence. Conclusion Writing user stories is an easy method of maintaining requirements in a dynamic environment of an Agile project. JIRA, as explained above, provides a powerful and rich set of features which helps manage requirements in an efficient and convenient manner.    
Rated 4.0/5 based on 1 customer reviews
3539
Writing Effective User Stories in JIRA

User stories are one of the main methods of commun... Read More

Project Manager Vs Product Owner

Traditional waterfall projects had the Project Manager unquestionably at the helm of the ship. Today, as more companies migrate toward agile, the role of the Project Manager has become redundant. Agile advocates team work — wherein there are self- organizing teams, and much of the responsibility that was earlier shouldered by the Project Manager is shared by the group. In an agile environment, the Product Owner owns the product, the Scrum Master owns the process and the team works together toward fulfilling the tasks. In a traditional project, the Project Manager holds all the cards and owns the entire project. Today, Project Managers need to redefine their responsibilities in the agile context, and depending on their inclination frequently take on the mantle of the Product Owner or ScrumMaster. There has been much heated debate on this topic in many online Scrum forums, with differing results … but research shows that there is no definitive answer that squarely references the PM to the PO. While Scrum rejects the role of a Project Manager per se, there are many who believe that this role has been reframed to include the two roles of a Product Owner and a ScrumMaster. The ScrumMaster is by definition a servant leader. The Product Owner, by definition, is the person who represents the business stakeholders and keeps the team focussed on the product itself. As a Product Owner, his or her job is to tell the team what to do…but not how to do it. The ‘how’ is decided by the team members themselves. And that, in a large part, sums up the difference between a Project Manager — who needed to spell out the Hows, Whats and Whys — and the Product Owner, for whom only the definition of the problem…or the What… is all-important. In Scrum, there is no single management position. And that’s where the beauty of Scrum, and perhaps its efficacy, lies. Scrum teams are self-managing, and when each member of a Scrum takes on some responsibility, the project has a much higher chance of success.
Rated 4.0/5 based on 20 customer reviews
Project Manager Vs Product Owner

Traditional waterfall projects had the Project Man... Read More

other Blogs