![\"Agile,](\"http:\/\/webfinancialsolutions.com\/wp-content\/uploads\/2012\/05\/Scrum-Blackboard-1024x412.jpg\")
<\/p>\n<\/p>\n
Sprint length is a topic of debate for companies employing Scrum. In my opinion, there is no one \u00abright\u00bb length for sprints because of the myriad of factors that influence how effective a specific sprint length can be for a company. Availability of stakeholders, the stage of the company and experience with scrum are all very important considerations when choosing the right length of sprints. What works in one situation may not work in another but it’s critical to set a fixed sprint length is to establish rhythm for the team. At AgilityFeat, we work in distributed\u00a0 teams. We’ve learned that the one week sprint is the best cadence for our teams and here’s why.<\/p>\n
As a company that is hired to develop products by our clients, we have found that investing in weekly demo sessions has enormous value for our clients. These demo sessions create regular intervals for our clients to view and use the software that we have built. This in turn enables the client to show development to their customers which can inject feedback from the market in near real time.<\/p>\n
Weekly Retrospectives<\/a> mean more opportunities for the team to discuss what is working and what needs to be improved. While it requires an increased level of discipline to conduct weekly Retrospective sessions, the increased number of cycles to try new things to improve the team’s performance enables a more rapid pattern of experiments and learning. One important key to running weekly retrospectives is to make them easy to run, document and act on. We use Sensei<\/a> to run our Retrospectives.<\/p>\n One week sprints means that stories need to be smaller to fit into the tighter time cadence. The requirement of smaller stories means that product owners have an increased ability to change the priority of user stories to react to changing conditions in the market or within their company. If an opportunity pops up for a feature that is lower in the product backlog<\/a> the product owner doesn’t have to wait weeks for the current sprint to complete. Instead, the product owner can react to the opportunity nearly immediately by pushing the feature to the top of the product backlog. As the Agile Manifesto<\/a> values \u00abresponding to change over following a plan\u00bb, weekly sprints maximize a team’s ability to respond to change.<\/p>\n Weekly demos force a team to confront any challenges that are slowing them down. Longer sprint cycles increase the opportunity for teams to work too long in the wrong direction or possibly to procrastinate and not uncover a challenge until it is too late for a product demo. One week sprints require that developers demo their work each week, which gives stakeholders a regular update on real progress of a project (vs reported progress). Further, it creates a healthy environment of open communication to clarify vague user stories or under-thought feature requests.<\/p>\n3. More control for product owners<\/h2>\n
4. Increased transparency for development<\/h2>\n