0

Let's suppose the business comes and asks you when will your team be able to deliver a big feature or release. In Scrum, how do you make long-term (half a year or a year) planning?

If the feature (or the release) is big, then the team can't accurately estimate it. You may try to break it down into small features that can be done during one Sprint, but this is a big upfront design, which we try to avoid in Agile, because things can change as we go and this upfront planning becomes a waste.

1
1

Scrum and its associated techniques don't eliminate the need for long-term planning but they can help make your planning and estimation tasks easier. If you deliver in fixed-length increments then your estimation only needs to be good enough to estimate the number of sprints a big ticket item will take rather than the number of days effort or duration. Relative estimation generally makes it easier to estimate the epics and stories whatever size they are.

When it comes to actual delivery, the iterative incremental approach means that risk is managed, priority items get delivered first and therefore there's a much stronger likelihood of meeting planned delivery dates. Adaptive agile approaches are sometimes understood as being the complete opposite of more predictive, planned approaches but in many ways the agile approach can help make the outcome more certain and predictable.

3
  • So, is it fair to say that you could provide an estimate with variable confidence as to when certain features will be delivered? - i.e. the top priority features are likely to be delivered within (x) sprints with high confidence, whereas lower priority or secondary features are to be expected within (y) sprints, with a higher level of variation or lower level of confidence? – Iain9688 Apr 27 at 10:59
  • Thank you, but you didn't explain anything about how to actually estimate a big feature/release ) – Daniel Apr 27 at 14:42
  • @Daniel, The best way to get an estimate is to ask the team who are actually going to do the work. That's true whether you are using Scrum or any other method. Fixed-length iterations, story mapping and relative estimation ("story points") are some techniques that can help the team estimate big features and releases. – nvogel Apr 27 at 16:45
1

It seems like this question is based on the misconception that decomposing a large feature into smaller units of work is a form of big design up-front. It's not. Big design up-front is designing the whole system, or at least large parts of a system, before starting any implementation and integration happens. Although decomposition is a design activity, it's not all of the design, and the smaller pieces enable small portions of the system to be designed, developed, and integrated. In other words, you're deferring the detailed design and implementation of parts of the system until it's needed, a key principle of Lean Software Development. This deferral could also lead to the decision not to do some of the work, a principle of Agile Software Development.

That said, there are two primary techniques that could fit into Scrum.

The first technique would be to integrate as much work as possible into each deliverable. In cases where it doesn't make sense to fully enable the work, there are techniques to hide the work. For example, in software systems, you can use techniques such as feature toggles (or feature flags), keystone interfaces, and dark launching to integrate the work into a single development stream, but enable or disable the work in different environments. As pieces that are fully functional make sense, those pieces can be enabled for end users.

A second option would be to keep the work in a parallel development stream. The work can be deployed to a test environment where stakeholders can provide feedback, but it won't be integrated until it's sufficiently complete. There may be several points at which enough work has been done to integrate, instead of just one at the completion of the feature.

The first option is probably more consistent with the Scrum mindset, but it isn't supported by all types of features or in all contexts. The end goal is to get rapid feedback on the work, regardless of that work being deployed for end-users to use or just in an environment to get stakeholder feedback. Once you reach this, you don't need to plan out so far.

4
  • Decomposing a large feature quickly brings up questions about the architecture of the product. And if you stop at this step, then these smaller features remain very abstract and the team is just not able to provide accurate estimations for abstract features.. – Daniel Apr 27 at 14:57
  • I don't mean that the business asks for approximate estimates - the business wants to know the date when the work will be done. – Daniel Apr 27 at 15:00
  • @Daniel Someone should explain to "the business" what the value of agility is. Not all projects can be accurately estimated and predicted up-front. Instead of trying to, agility is about finding ways to respond to the uncertainty and ambiguity that exists in projects and adapt to the changing environment. If you can have a reasonable estimate early in the project, then perhaps the agile methods aren't appropriate because the ways they handle uncertainty would add overhead to more certain efforts. – Thomas Owens Apr 27 at 18:05
  • @Daniel As far as large features quickly bringing up the architecture, consider techniques such as "incremental design" and "simple design". These practices are associated with Extreme Programming, but have spread to other agile software development methodologies as well. You don't need to decide everything now, especially if you aren't estimating all of the features. – Thomas Owens Apr 27 at 18:07

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.