please substantiate the answers with valid data points, on why you feel that complexity of a project is a determining factor of sprint length
3
-
1Your title and description don't match. Are you asking about when the project is complex, or the stories for that sprint are complex? Those are two very different situations.– SarovCommented Oct 15, 2020 at 20:52
-
Dynamic Sprint lengths are a framework anti-pattern. Average PBI size (which may include complexity considerations) is only one factor among many that affect optimum Sprint length selection. Without more detail in the question, the OP is just a polling question, and should probably be closed unless it's edited to include more context about the specific problem to be solved.– Todd A. Jacobs ♦Commented Oct 17, 2020 at 11:41
-
Not sure why we'd re-open this question until the issues raised are addressed.– MCWCommented Nov 2, 2020 at 12:55
Add a comment
|
3 Answers
Each team chooses their own Sprint length depending on their particular context. The Scrum Guide only says that a sprint is one month or less.
So the team decides on what criteria to support their decision for choosing a particular length or another. And, yes, the complexity of the stories can be such a criteria.
Sprints are used to accomplish something. Each Sprint has a goal of what is to be built, a design and flexible plan that will guide building it, the work, and the resultant product increment.
If your stories are big and complex, they might not fit a small sprint. So teams might choose a larger sprint length for this reason. There are no rules defined in Scrum to say that this is a good or a bad thing. The team decides.
Most teams choose two weeks. Is that based on some careful analysis or best practices? Not necessarily. Many times it's because one week feels too short, while three or four weeks seem too long.
The question now becomes: is it a good idea to use complexity of the stories as a factor in choosing the sprint length?
Again, there are no rules, but in practice, shorter sprints tend to behave better (you have shorter feedback, delivery, and inspect and adapt cycles, etc). Teams (especially inexperienced ones) tend to chose a larger sprint length because they think they have more time available to do the work. Unfortunately, a longer sprint introduces more assumptions, more risks, and more uncertainties. Experienced teams know that they don't necessarily need more time, but a way to better decompose the work so that it fits within the sprint (of whatever length they chose).
See the following links for a more in depth explanation:
No. Complexity shouldn't determine the length of a sprint. Let me point out that you actually asked two questions. The title of your question asks about complexity of stories but the body of your question asks about the complexity of the project.
The point is that, irrespective of complexity, the team ought to be able to construct stories small enough to fit into a sprint. Assuming this is a software development project, the operating model (e.g. devops / deployment pipeline and the ability of the customer to review and use the product) has more influence on sprint duration. The size of the team may also be a factor. If in doubt, for a new piece of work start with a sprint of one or two weeks and use that as a good discipline to encourage the team to write suitably sized stories.
-
It is good to be able to break down stories small enough to fit in an arbitrary sprint length, but sometimes it either isn't possible, or more likely would result in significant inefficiencies, in which case you don't want to do it. Commented Oct 16, 2020 at 18:08
No.
The length of the Sprint is determined by the Scrum Teams, considering the synchronization between the Scrum Team(s) and the stakeholders. The Scrum Guide states that a Sprint is at most 1 month in duration. This means that stakeholders should synchronize with each other at least once every month.
Aside from that minimum synchronization cadence, the factors to consider include how often customers and/or end-users can review and accept product Increments, the frequency of change in the marketplace, the frequency of change in schedule or budget, and the cadences of other teams in the organization. The complexity of the items in the Product Backlog is not a factor.
Although Sprint length can be changed, it shouldn't frequently change. This lets the team fall into a regular cadence and have a much more stable concept of capacity. It also reduces decisions, preventing decision fatigue regarding when to hold the Scrum Events.
answered Oct 15, 2020 at 12:22
-
@DJClayworth It does. The very first word answers that question. The second paragraph tells you what should influence the choice of Sprint length. The only factor to consider is stakeholder synchronization.– Thomas Owens ♦Commented Oct 16, 2020 at 18:13
-
@DJClayworth I never said that the stakeholders decide the Sprint length, because they don't. The team decides the Sprint length. In a scaled environment (depending on the framework used), the teams may need to coordinate on Sprint length. The only thing that matters is the Scrum Team to synchronizing with stakeholders. You should not have a Sprint shorter than the synchronization period. In other words, how often can the stakeholders synchronize at the Sprint Review and be ready to review and accept a potentially releasable Increment? Story complexity has nothing to do with that.– Thomas Owens ♦Commented Oct 16, 2020 at 18:18
-
You are correctly quoting the standard answers for basic agile, but not really considering the complexity. The synchronization frequency is rarely decided by a single factor. A given project may wish to trade a lower synchronization frequency for higher efficiency. Like many things its a balance, and complexity of story is at least conceivably a factor in that calculation. Anyway, that's my view. You are entitled to a different one. Commented Oct 16, 2020 at 18:22
-
@DJClayworth Since a Sprint length is generally fixed for an extended period of time, I'm not sure how you can consider story (or, more generally, PBI) complexity. The only factor is how frequently you need to synchronize with stakeholders. How frequently can our customers or end-users review and accept Increments? How frequently is the marketplace changing? How frequently is the timeline or budget changing? What are the cadences of other teams? There may be more, but the complexity of backlog items is not one of them.– Thomas Owens ♦Commented Oct 16, 2020 at 18:26
-
Ah, you mean "should the sprint length be changed during a project to accommodate story complexity". I don't think that is what the question means. I think it means should the story complexity expected in the project influence the initial choice of sprint length. Commented Oct 16, 2020 at 18:31