TL;DR
I provide a little more dos-and-don'ts below, but here's the executive summary:
- Don't conflate level-of-effort with complexity, although they can be related.
- Don't treat story points as "victory points" or "effort expended"; they should be treated as level-of-effort estimates to determine if they are likely to fit within the time box of a single Sprint.
- Don't automatically roll over user stories if you're using a time boxing framework like Scrum. Other non-Scrum frameworks may have different rules or guidelines.
- Don't miss the opportunity to continuously re-evaluate, inspect, and adapt your planning and estimation processes to ensure you have sufficient slack and a defined process for handling overflow or mis-estimations.
User Stories are Primarily About Level-of-Effort
[W]e are assigning story points based on complexity.
This is only part of how one should estimate user stories. Mike Cohn, author of User Stories Applied and other books on the topic, has occasionally taken both sides of the argument of whether complexity should be a factor in estimation. However, the generally-held consensus among experienced practitioners is that story points should primarily reflect a relative level-of-effort compared to a baseline story, e.g. a 2-point story will require twice as much effort as a 1-point story.
Of course, the cone of uncertainty and the complexity inherent in a user story (among other factors) will potentially impact the level-of-effort required to deliver the story, so you should take those things into account when estimating and planning. You can do this by applying suitable "fudge factors," or by splitting stories or creating story spikes to reduce uncertainty and create bounding boxes for your estimates.
User Story Scope Problems
If we get unexpected situations like server unreachable, network down, dependent items, or delays, can we increase the story points for a user story in the middle of a Sprint[?]
No, you should not change the story points estimated for a Product Backlog item during or after the Sprint. The story points are a planning and estimation tool. If the planning or estimation were wrong, you actually need the original data from the original estimate to properly track velocity. That said, some systems do track "planned story points" and "consumed story points" as separate metrics, but overall this is an anti-pattern where velocity is being used as a proxy for measuring team or individual productivity rather than as a feedback mechanism to improve the estimation and planning process.
Note: The Product Backlog and Sprint Backlog are different things.
If you maintain a separate Sprint Backlog (where items are often estimated in 1/2 to 2-day increments rather than story points), you can certainly decompose, move, or re-estimate your Sprint Backlog items to reflect the current reality of what the team is doing so long as it doesn't endanger the current Sprint Goal or your non-Scrum objective for the current Sprint. However, the original planning estimate for the Product Backlog item should never change.
If the expected scope, complexity, or level-of-effort for a Product Backlog expands during the Sprint, or the level of effort is significantly off from the planned level of effort, then you should follow your team's process for escalating the matter. If you were following Scrum, the escalation process would look like this:
- Determine whether the user story's mis-estimation puts the Sprint Goal at risk.
- Discuss the scope, challenges, and value of the user story within the current Sprint with the whole team, including the Product Owner.
- The Product Owner is empowered to negotiate the scope of Product Backlog items downwards for the Sprint, or to call for an early termination of the Sprint and a return to Sprint Planning if the Sprint Goal is at risk.
- The whole team should definitely discuss the estimation process, available slack for handling unforeseen events, and how to handle "known unknowns" in its Sprint Retrospective before re-estimating stories like these.
Changing the story points for a Product Backlog item after the Sprint is completed (assuming the story is done per the Definition of Done) is an attempt to get credit for effort expended rather than increments delivered. This is such a whiffy agile anti-pattern that I will simply say that doing this undercuts the entire basis for using story-point estimation in the first place. Do not do this.
Rolling Over User Stories
[Can we] request that the user story roll over into the next Sprint?
If you're following canonical Scrum, the answer is "no." In the Scrum framework, incomplete user stories are simply not done and must be placed back onto the Product Backlog for re-prioritization by the Product Owner and (possibly) selected for inclusion in a future Sprint where that user story is needed to meet that Sprint's current Sprint Goal. For more on this, see the following related answers:
Of course, if you're using some other agile framework that doesn't require either time boxing or a coherent Sprint Goal, you may be able to simply roll stories over. I would personally still consider that an anti-pattern since the agile process you've described in your question implicitly uses Sprints for time boxing, but if your framework and working agreements permit rolling over work without re-estimating and re-planning, then go ahead and do that. Just don't waste the opportunity to inspect-and-adapt your estimation and planning processes so that this doesn't become a routine occurrence!
See Also
The following are Scrum-oriented, but seem relevant to the questions you're asking. They may provide some additional context for you.
