Big tasks vs short list of small ones at sprint planning meeting

Question

Simply: Sprint planning, we do not have well described user stories and we need to create tasks (since we do PoC-like module, technology remain somewhat unknown). Should a team either:

1. Create big tasks that cover teams capacity completely. Then tasks in our view are not defined well. or
2. Create short but incomplete list of small tasks that can be started at the beginning of the sprint. Later on we add consecutive tasks that will emerge naturally. Then our initial workload is only 1/3 of our capacity.

ADDED: We are lacking domain knowledge and PO needs a couple of weeks to work it out. I just want to know that if it is okay to start the sprint with incomplete list of tasks for the whole sprint (we have user stories, but things change very rapidly during the sprint).

Which one is a pragmatic Scrum standard or just better in terms of your experience?

Answer 1

Smaller tasks are more easily estimated and implemented. Smaller tasks also make it easier to identify when you're "done" with the particular task.

The ideal Agile process is highly iterative, so having lots of short but incomplete lists of small tasks makes it easier to iterate through and develop the proof of concept that you're looking for.

Likewise, with big tasks, they are harder to estimate accurately; have a really bad tendency of bleeding over into the next sprint; and are horrifically subject to "scope creep" where the developer constantly realizes "Oh yeah! We need to have baz feature along with foo and bar"

Answer 2

Which is Scrum standard/better in terms of your experience?

Getting user stories well defined. If necessary, that means getting the product owner in your sprint planning to answer questions. That will lead to two sort of scenarios:

1. You get your questions answered. Sweet, now you can make your small well-defined stories as you normally would.
2. Nobody knows what's going on, so you need to investigate.

I'll focus on the latter case, since that seems to be what you have. In that case, what I've seen work best is to not do a lot of sprint planning. "Okay Bob, we need to figure out how to do XYZ - what do you think you'll be able to show in 2 weeks?" Bob gives some tentative goal, everyone agrees and Bob can go dig into stuff.

Bob then keeps everyone up to date during standup, which also provides opportunity to manage expectations about that tentative goal. If he can define tasks for the different parts of investigation, great. That is really only necessary if there are others that need to work on the tasks.

Having formal tasks for this sort of work is only counterproductive in my experience. They are going to be tiny or vague. Tiny stories just increase overhead and cause clutter. Vague stories just cause project managers to interfere and provide no value.

The main thing to remember is that as soon as Bob starts saying "I made..." you stop him and make tasks. Research is a vague, exploratory affair. Implementation (even prototypes) is not. Once you found out what you need to find out, go back to the better process.

Answer 3

I'd say that something like a tree structure works best. You have a few huge 'root' tasks, detailed into smaller but still large tasks, split into small, less-than-a-day, easy-to-track 'leaf' tasks.

What you discuss for sprint intake is leaf tasks. But you can always trace them back to a bigger picture, which helps understand which small tasks are more worth taking. Also, you can sort-of track the scope and progress of the big tasks.

An example:

• Implement user authentication / authorization (a huge task)
  • ...
  • Implement social login (a large task)
    • ...
    • Get an OpenID example working (a leaf task)
    • Get a Google OAuth2 example working (a leaf task)