Most people agree that it is a good thing to split a software development project into many small tasks each of which can be implemented within a few hours. But the finer the granularity, the more total effort has to be put into defining the exact scopes of all the individual tasks in order to avoid gaps or overlap.

My question is not about how to break down a complex system but on how to document the result once you have done it: How can we clearly define the scope of a task so that a developer to which it is assigned will neither implement too little nor too much?

I am aware that the scope of my question is rather broad but I hope that there are some general strategies, guidelines or best practices. I have been searching for information about this topic for quite a while now but am not happy with what I found so far.

I believe that agile practices help to reduce the impact of ambiguous task definitions but do not address the issue itself.

  • 1
    My answer would be, "Using words. If it's not clear enough, use more words. If it's still not clear, use different words, maybe diagrams." But I feel like this is a human communication problem rather than a software engineering one. And yes, it is too broad.
    – scriptin
    Commented Jul 22, 2017 at 19:39
  • @scriptin: I am not convinced. There are loads of theories on how to improve software project management. I can't believe that the answer to such an essential part of it is just "use words...". And the longer I practice software engineering, the more I feel it's all about human communication. Therefore I don't think it's off-topic. Commented Jul 22, 2017 at 21:35
  • Well, there's the problem: "There are loads of theories..." If you could narrow your question to some specific project management problem, you could get more specific and detailed answers than just "use words". There are things like user stories, software requirements specifications, etc., but it's impossible to cover them all in one answer.
    – scriptin
    Commented Jul 22, 2017 at 21:58
  • @scriptin: Right, there are lots of recommendations on how to write user stories and other types of requirements. But my question is about tasks. Tasks are not requirements. They serve a different purpose and there is no 1:1 mapping between tasks and requirements. Commented Jul 23, 2017 at 7:26

1 Answer 1


How can we clearly define the scope of a task so that a developer to which it is assigned will neither implement too little nor too much?

By providing a definition of done.

For stories these are called acceptance criteria. For every task though you explain what you plan to do. When you're done you explain what was done. Hopefully these match up. When they don't make clear how they don't so new work can be planned accordingly. Not everything goes perfectly to plan. Don't pretend it has. I never simply tell people something is done. I say what was done.

If you're looking to control how the work is implemented you're looking in the wrong place. Scrum doesn't care about how.

  • And the answer is the same outside of scrum.... Commented Jul 24, 2017 at 22:12

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.