Lately there has been much talk about agile software development and the best way to plan a successful sprint that meets the costumer business needs. We can say that the duration of the sprint greatly influences the end result of successful software deliveries, and this goes against the cultural aspects of each company, business dynamism and user expectations.
As a rule, there is a proposed duration between 2 to 4 weeks of sprint, in an agile model of development, but often, due to the dynamism of the business and the needs of users, this length of time can and should be shortened. What is the problem with having one week sprints? Often the time spent in planning short sprints is rewarded with quick deliveries that satisfy the customer, but more importantly, we mitigate the risk of change along the way. Remember that this scenario only be applied for a process that the software deployment is fast or continuous, otherwise it could not be possible to deliver the planned features in a short period of time.
In a corporate environment where changes are constant, and the predictability level of these changes is also low, it is better to plan shorter duration sprints, which are less likely to risk mid-shift changes. Remember that during the course of the sprint we should not change the sprint backlog previously planned. The sprint burndown chart should reflect the planned tasks as close as possible to the planned, during the execution of the sprint. In this way, to avoid problems in sprint management and planning, it is ideal to decrease the duration of the sprint.