Is it possible to give timelines in SCRUM?

Question

Our team is currently using a very SCRUM near approach in planning and development. But I constantly face one issue with our management. The management is part of the backlog priority process and each time I am confronted with the question: "When will this feature be done and available?", a second after we set the priority in the backlog.

My (maybe limited) understanding of SCRUM was always that you set the priority and then pick up tasks based on priority and put them in Sprints. I would put as much tasks in the Sprints as the team capacity would allow me to. Therefore I could only give out timelines when the task is in a Sprint. But usually the management want to know immediately after the priority get set. Also if I would be providing a timeline I have the feeling that this is a setup for disappointment since priorities can change and unforeseen things like bug fixes can delay certain new features.

Also we are using JIRA as a tool and to be able to comply with that request of timelines I would need to have a way which calculates the timeline automatically based on the estimates. But I do not see any way to do this in JIRA.

So how could I solve this issue? Are timelines non-agile / -SCRUM or should a timeline be always possible for tasks that are months in the future.

Answer 1

Like most things, it depends.

In theory, you could forecast when work is likely to be done. If you understand your team's average velocity (whether it's in story points per Sprint, ideal hours per Sprint, backlog items per Sprint), you can forecast when you will get to a particular item on the backlog. However, there are a lot of caveats with this. It depends on all of the work up until the item in question being well-refined and estimated. It also assumes that the ordering of work (including additions and removals) is fixed. The team's velocity may change over time (in either direction) for a number of different reasons. Any such forecast, especially if it's more than a couple of Sprints out, has a lot of variability. The forecast is an "as-is" snapshot that could change on a daily basis, as the backlog changes.

In practice, I would be extremely hesitant to even attempt to forecast anything more than what is being done in the current Sprint and perhaps likely for the next Sprint. If you are truly embracing agility, which includes responsiveness to changes and feedback, you need to be adaptive. It's not uncommon for people to turn estimates and forecasts into deadlines. Having committed deadlines makes it more difficult to be responsive to change, especially if you're trying to maintain a sustainable pace of working.

The best thing to do is to work with all of the stakeholders to understand tradeoffs. Rather than forecasting dates, get the work in the right order. If there is work that has deadlines, after which the work is no longer valuable, this should be considered when ordering the backlog.

Answer 2

The tool you want is a burnup chart. JIRA has them built in as Release Burnup Chart or Release Forecast Chart (they keep changing the name), but the feature in JIRA is limited that it only forecasts the whole release. However, you can build these charts by hand - they may seem difficult at first, but they're very fast and very easy once you get the hang of it. Built by hand you can forecast specific features easier.

There are a few things you and your manager should know about this tool:

1. it gives you a view of things as you know them today. Your learning evolves and so the chart will change as you learn more and progress. In reality, there is nothing new here, but GANTT charts gave the illusion of certainty. Any project managers knows, however, that GANTT charts change all the time as the project progresses.

2. Burnup charts give a range - usually from pessimistic forecast to average to optimistic. If you take your most optimistic forecast and promise it to the CEO, you've dug your own grave.

Finally, a small tip, for large numbers of backlog items, counting items is often just as accurate or almost as accurate as using the estimates unless you have wildly different-sized items.

Answer 3

Are timelines non-agile/-SCRUM or should a timeline be always possible for tasks that are months in the future.

You can always do a long(er) term release planning no matter if you use Scrum or anything else. You basically look at the features you want done, estimate each and every one of them, then knowing the team's velocity and the length of a sprint in days/weeks, you can forecast a timeline.

But of course, as you mentioned yourself, a lot of things can happen between the time you make this forecast and the moment when your release will be "actually done". Agile practices like Scrum recognize this as a reality and don't try to estimate everything upfront and predict when everything will be done. Scope is flexible in Scrum. An upfront release planning fixes scope. Actually it fixes scope in the imagination of people because as you work on your product, you discover new insights, stuff occurs, changes are needed, etc., so scope will inevitability change if you want to build THE RIGHT product and not SOME product you imagined at the beginning (when you know the least about it).

See for example this explanation for how a longer release planning can be done with Scrum. You can do it, but you have no guarantees that you will actually make it happen, because things evolve. That's one reason why in Scrum the product backlog is prioritized and detailed and estimated at the top, and things get blurry as you go down, because you don't try to build a bunch of features, you want to build the right features. So figuring out now what will be available months from now is a bad idea, and usually a waste, and not just with Scrum, but in general. If you decided that you will build feature F two months from now, doesn't magically make the feature a part of the product, because two months from now, because of various reasons, that feature might be completely useless or even detrimental to the product.

Agile, and Scrum also, need a collaboration between the development team and those asking for the product. What your management is trying to do is "to be excused" from this collaboration and just expect you to build things when they want it. And changing the way they view development and what their role is in everything, will be unfortunately way harder than giving timelines with Scrum.

Answer 4

Estimates and velocity are the answer to your question. Nothing about Scrum stops the team from estimating work (and it should be the team who does so, not any one person). The scrum approach helps with estimation and scrum teams normally base their forecasts on velocity (evidence based on previous results) rather than any more speculative predictions.

Answer 5

It is not less possible to give timelines in Scrum than in other methodologies.

The main difference is that in Scrum we are not encouraged to blatantly lie, that is why we have to ask the team to estimate product backlog items and that is why we consider any burndown or burnup a forecast only.

Giving timelines is not any better in a traditional PMI project. Deadlines are rarely met, perhaps when generous contingencies are added to the estimates and overtime is enforced.

Answer 6

If we assume that you have a fairly mature Scrum team working on the project - meaning that they have a good spread of appropriate technical skills, work well together, follow the Scrum practices appropriately, and have reached a point in both productivity and estimation that they are regularly able to deliver the Sprint Goal without being heavily over- or under-worked, then:

1. Any Product Backlog item should be placed in a position on the backlog representing its priority relative to the other PBIs per the Product Owner's understanding of the current state of the Product.

2. Any Product Backlog item should be estimable, meaning that the team has some idea of how simple or complicated it is relative to other tasks, and hence of their capability of completing it if it were included in a Sprint. (This could be done in terms of Story Points or any other manner, like T-Shirt sizes or world monuments or whatever, as long as the team understands how the values relate to each other.)

3. The Product Backlog items near the top of the backlog will, on average, be better understood, more clearly defined, smaller and have fewer unmet preconditions than the ones further down the Backlog - i.e. they should be more ready, with the items right up the top being potentially ready to be worked on right away.

With this being the case, the Product Owner should be able to essentially just draw a line somewhere in the Product Backlog and say "This is what we are delivering next Sprint", and the Scrum Team should be close enough to agreeing with this that they can negotiate and adjust the point up or down a few items.

This also means that the Product Owner should be able to draw multiple lines down the Product Backlog, each representing a Sprint's worth of work. If you do that, then you have an estimate of how long it will take for any given item to be completed, since it's just a function of how many Sprints away it is and how long your Sprints are.

However, you have to keep an eye on points 1 and 3 above. Each Sprint Review is a discussion between the Scrum Team and the customer, and it represents a point at which the Product Owner may decide to change the order of items in the Backlog, or even change what items are represented in the Backlog at all. Additionally, anything that's further down the Backlog is by nature clouded in uncertainty - something that's currently 1 Sprint down in the Backlog will probably wind up in the next Sprint, but something that's 4 Sprints down might wind up being worked on 3 Sprints from now, or 5. It might be split into 3 different items because it actually involves multiple major developments, or the team might need to invest in a research spike to even understand what developing that feature even entails.

A lot of Waterfall-style projects tend to assume that the milestones planned at the start of the project are perfectly estimated and predictable, but if you're working in a Scrum team then there's a decent chance that your product doesn't fit well in that paradigm in the first place, and the stakeholders who are breathing down your neck asking for perfectly accountable timeframes are going to struggle to get used to this, but hopefully if they are involved in the key parts of the Scrum process (especially Sprint Review, where they can see both the incremental development of the Product and the adjustment of the Product Backlog) then they will start to learn the value of embracing this uncertainty - which is always going to be there, but made much more overt in Scrum than in Waterfall.

Answer 7

If you are doing scrum then estimating the timeline for the whole project is not feasible. It can only work if are adopting the agile approach, which requires that the timelines are dependent on what the product owner has prioritized in the product backlog. Furthermore, When the development team has decided on the number of features to build in a sprint, the dev team can estimate the effort it will take to build a feature in form of story points. The total number of story points in a sprint backlog is the effort and time required to build the features.