Breaking down stories/tasks
I am running into a situation with the team where the tool of choice isnt allowing for the desired status workflow - it limits to a pre-defined flow we need to fit into. Each stage has several steps that must be completed - example, development includes back-end development, front-end development and some code review - which are all done by potentially different resources. So the team wants to capture each task and story point them. This is leading to TOO MANY tasks per Story - potentially 7-8 per story's lifecyle. Personally I dont see any other way to ensure all work effort is being tracked. Does anyone else have any suggestion?
This is leading to TOO MANY tasks per Story - potentially 7-8 per story's lifecyle. Personally I dont see any other way to ensure all work effort is being tracked. Does anyone else have any suggestion?
Is it the development team who is not able to track their work towards the Sprint Goal by breaking down the story into smaller pieces ?
How does the development team feel about their transparency, predictability and ability to track progress towards achieving the sprint goal?
"Way too many tasks" is subjective, and it all comes down to answering the questions above.
The team should ideally be self organizing in finding a way that works for them
Scenario is such that they feel the need to break down to several tasks due to multiple parties involved in performing the tasks including stakeholders/client. So from a visibility standpoint - it makes perfect sense; however its a lot of overhead for the team having to create these tasks. Unfortunately there isnt a way to "template" these stories with the child tasks either (Although they are mostly cookie cutter).
If you have a workflow that is as granular as you indicate why do you also need a task for the work? Couldn't you move a story across the workflow and indicate when the story is in front-end development, back-end development, code-review, etc? It can be understood that different people will be working on the story in different phases of the workflow and the Daily Scrum can be used to discuss the current state of the work in each phase. Point the entire story not individual tasks. This is basically a Kanban flow but it can still work within Scrum Sprints.
Often it is better to eliminate dependencies, rather than manage them.
Could the real problem be that no single team is able to add value by itself?
Do people need to reorganize/retrain/hire in order to form a team that can deliver value without having to perform handoffs?
Note: There is nothing in Scrum that says a client or stakeholder cannot be part of a Scrum Team.
Scenario is such that they feel the need to break down to several tasks due to multiple parties involved in performing the tasks including stakeholders/client.
If those parties are doing work which is necessary to achieve the Sprint Goal, then perhaps they ought to be members of the Development Team. Remember that the Development Team should include all of the skills and capabilities required to create a Done increment which meets the Goal.
It is conceivable that, through the collaboration of the right team members, task planning might become somewhat less explicit. If this isn't possible, then the team will need transparency over their external dependencies, and the ability to manage them.