1

Can anybody answer my question here? I have estimated for 5 to 6 tasks like analysis (4 hrs), design (3 hrs), logical review (1 hr), peer review (1 hr), unit testing (1 hr), coding (2 hrs) and release (1 hr). But during analysis itself I came to know that rest of the activity will not be applicable. In this scenario, should I make the hours zero for all the tasks that have become obsolete or should I delete the tasks?

Improve this question
2
  • Please clarify your specific problem or add additional details to highlight exactly what you need. As it's currently written, it’s hard to tell exactly what you're asking. See the How to Ask page for help clarifying this question.
    – Todd A. Jacobs ♦
    Jan 8, 2015 at 20:23
  • @CodeGnome, the question is quite clear. Please see my answer for more details.
    – David Arno
    Jan 9, 2015 at 9:10

3 Answers 3

Reset to default
3

Use research stories to minimize uncertainty

Here is what the bible of Scrum practitioners, the Scrum Guide, says about the Sprint Backlog:

As new work is required, the Development Team adds it to the Sprint Backlog. As work is performed or completed, the estimated remaining work is updated. When elements of the plan are deemed unnecessary, they are removed. Only the Development Team can change its Sprint Backlog during a Sprint. The Sprint Backlog is a highly visible, real-time picture of the work that the Development Team plans to accomplish during the Sprint, and it belongs solely to the Development Team.

So, if you have determined that some of the tasks are not necessary, remove them.

@David Arno suggested approaches for filling the gap in the Sprint. However, if this frequently happens or if it is a major part of your Sprint, you should consider doing a time-boxed research story (also known as a spike) in a previous sprint. The same analysis, possibly including a minimal proof-of-concept, will allow you to plan with more confidence.

Improve this answer
1

Delete the tasks.

If you find yourself writing the same tasks like j-unit, dev testing, etc for all your stories/backlogs, they are not tasks, they are done criteria and can be rolled into a higher level task such as "implement XYZ as part of the solution."

Try and minimize the overhead associated with creating and managing task level details within the iteration if it is not adding any value.

Improve this answer
0

The first point to make is that I'd suggest you are breaking your tasks down to too fine a detail and are creating a mini waterfall within your sprint. Unit testing and coding are typically done at the same time, so having two separate tasks will likely cause problems. If you adopt TDD principals, the act of writing the tests and developing the code is the design etc.

Having said that, your tasks are what they are. If one task has rendered others irrelevant then, depending on circumstances you'd normally do one of the following:

  1. If there are plenty of other tasks assigned to the sprint, then just remove the unneeded ones from it. Then discuss with the scrum master and product owner whether it's possible to add other tasks (from the backlog) to the sprint instead.

  2. If the tasks to be removed make up the bulk of the remaining sprint, then advise the product owner that the sprint should be abandoned and the end/start sprint meetings should then be bought forward and a new sprint planned.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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