0

How should sprint tasks be planned when you won't know the next task to be done until the current task is complete? For instance, consider the case of optimizing a program's performance. Until you fix the current bottleneck (which may take much less than a single sprint), it's difficult to figure out what the next bottleneck will be or how long it will take to fix that next bottleneck.

How should you do sprint planning when you don't have visibility into tasks beyond the current one?

| improve this question | |
  • 1
    Are you saying that you have 0 visibility into next work? Since this is tagged as Scrum, this means that the Product Backlog has 0 things in it. It's true that some work may emerge only after existing work has been done and deployed. But there should be some idea of what can be done to continue to evolve the product. If not, I'd have serious questions about what the Product Owner is doing. – Thomas Owens♦ Jul 15 '19 at 15:22
  • I have visibility into the immediate next task, but not into task T+1 (because understanding T+1 requires completing the current task). Edit: Also we are still learning to do proper scrum (and this question is part of that learning :-) ) – Thomas Johnson Jul 15 '19 at 15:23
  • 1
    A single task? You don't have a Product Backlog? Based on what you're describing, I don't believe that Scrum is an appropriate framework for managing your work. – Thomas Owens♦ Jul 15 '19 at 15:25
  • 2
    And this really isn't limited to Scrum. How can you plan anything (regardless of methodology) if you don't know what the next tasks are? – Eric King Jul 15 '19 at 15:39
  • It sounds like your "tasks" may be too fine-grained. If the program is too slow, then your task is to make it faster, not to optimise function foo() in module bar. – Simon B Jul 15 '19 at 15:43
3

It sounds to me that its not so much that you don't know what the next task is but that you don't understand how to achieve the task. ie. It requires investigation.

So the story/task is "Make the program run in under 3 seconds". You know that you have some slow SQL in there, which you have a good idea about how you might improve it. But you don't know if the improvement will bring the time down to under 3 sec. If not, you'll have to do more, unknown, things.

In this case it's better to say that the task as a whole requires investigation, or a "spike" to see if you can find a solution which will achieve the goals.

In this case the spike is probably just screwing with the code until you get the time down. But then at least you have a solution, and you can potentially roll it out to multiple programs.

Say for example you found that reversing the polarity on the main deflector makes all sql run 30% faster and takes 20min per database. Now you can line up a bunch of well estimated tasks, even if the first one was essentially unestimatable.

More usually a spike will be "see if upgrading the db to mssql2020 makes it run faster" or something. So you are working in a dev env and will still have 'real' tasks to do even after the spike is complete.

| improve this answer | |
1

Until you have a Product Backlog, Scrum is not going to be effective. The Product Backlog is "an ordered list of everything that is known to be needed in the product". The ordering takes into account the priority of the work, dependencies between work items, and the level of effort. The Product Owner is the person who is responsible for ordering the Product Backlog and ensuring that the Development Team is focused on maximizing value delivered at the end of each Sprint. Typically, teams will have one or two Sprints worth of work refined at any given moment in time and will be spending about 10% (not a timebox or limit) each Sprint to work on refining the work defined in the Product Backlog.

Given the information I have, I'm not sure if there needs to be an intensive effort to put together a vision for the product in the form of a Product Backlog or if it's truly not feasible. If it's not feasible to have a sufficient Product Backlog, perhaps Scrum and it's structure around Sprint Planning and Product Backlog management may not be an appropriate fit for your product and team.

| improve this answer | |
  • It seems weird to suggest that an organization that needs to do some on-the-fly in-production performance tweaks is not suited for Scrum. – Graham Jul 15 '19 at 16:40
  • @Graham That's not what I'm suggesting. But if that's all you are doing and you have no defined Product Backlog, Scrum adds a lot of overhead that is unnecessary. You may be able to take some ideas from Scrum, but you probably would want to change key aspects that would make the end result not Scrum. – Thomas Owens♦ Jul 15 '19 at 16:42
  • I don't understand why you say there's "no defined Product Backlog". That doesn't appear in the Question. What if we have a backlog, but we also have a performance problem in production that needs to be tweaked NOW until its resolved? – Graham Jul 15 '19 at 16:44
  • @Graham The question says that the asker does not know the next tasks until the current task is complete. I've asked for clarification in the comments on the question, but until clarified, this implies that nothing is known beyond the current work - there is nothing in the Product Backlog. – Thomas Owens♦ Jul 15 '19 at 16:46
  • Ahh, I took it to mean that they didn't know the next performance-related task until they finish the current one (which may or may not solve the problem), but perhaps you are correct. – Graham Jul 15 '19 at 16:50

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.