Breaking down user stories into "real" units of work
Hello
I have recently joined a development team as PO. It's a new role to me - my background is in Project Management.
We made a quick decision as a team to introduce Scrum and it has largely been going well - we've seen improved levels of communication and collaboration in our first couple of Sprints.
There are a few areas which we need to work on improving and this is the first I would like advice on for the team.
The work the team pulls into the Sprint is articulated in user stories which tend to be quite abstract. We use Trello and a a physical board to track progress of each user story through the process (to do, in progress... etc.). What we're finding is that there are some non-functional things the team just has to do as it's a new product e.g. setup environments, research, datastore setup etc. Whilst the user stories rely on these things, they don't align nicely with only one user story and sometimes are quite big and important tasks. Wrongly, but for speed, we have divided these out and are effectively treating these like user stories even though they're not and don't fit the creation template. In the Sprint planning meeting the team reviews the user stories and can break them down into more appropriate "technical tasks" but that can mean multiple technical tasks for a user story and potentially multiple people working on a user story. It effectively creates another level in the hierarchy for managing work which complicates things.
Can anyone share how they do this. Do you break down user stories into technical tasks for developers to work on? Where do you record and track these? Are your backlogs still managed at user story level? Does anyone use Trello and can offer any insights?
Thanks in advance.
What we're finding is that there are some non-functional things the team just has to do as it's a new product e.g. setup environments, research, datastore setup etc. Whilst the user stories rely on these things, they don't align nicely with only one user story and sometimes are quite big and important tasks.
Then try and express them that way. They are tasks which are not specifically associated with any one Product Backlog Item, but rather with the Sprint itself.
...but that can mean multiple technical tasks for a user story and potentially multiple people working on a user story.
Aren’t team members normally collaborating to complete each user story? If not, why not?
Thanks for your reply, Ian. Much appreciated.
How would you suggest expressing them? Another entry in the Product Backlog but not expressed as a user story which is pulled into the Sprint in the same way as a user story? Is there a template for something like this which the industry uses?
Yes, team members are collaborating but why make something more complicated for the sake of it? We only want to split work if there's a benefit of doing so.
How would you suggest expressing them? Another entry in the Product Backlog but not expressed as a user story which is pulled into the Sprint in the same way as a user story?
Yes, the team would then apply their focus on completing that item.
Collaboration amongst team members ought not to be seen as a complicating activity but rather as a simplifying one, in so far as work in progress is limited and transparency over it is improved.
The work the team pulls into the Sprint is articulated in user stories
Mike,
- User Stories are just one way of expressing Backlog Items. A Product Backlog can contain anything ranging from User stories, Tasks, Epics, Technical requirements, NFRs, functional requirements, performance requirements etc. Not just user stories. And some teams and products do not even use user stories and they are not mentioned a a requirement in Scrum guide.
- Your non functional requirements can be part of PBI (user story or not) or seperate PBI under a Feature backlog item (logicay binded under the final feature you are trying to deliver)
- Also keep focus on vertical slicing. For example setting up environment and database are usually included within the FIRST functionality that you are trying to deliver. Each subsequent functionality (User story, feature , epic, whatever you used to logically group and define it under) will of course consume less time as the corresponding tasks for the new items would be (update environment to accommodate the new feature, update data structure or API to serve the new feature , but no build these from scratch like you did for you first PBI). The idea is to develop a thin slice of functionality to make sure all these layers that you envisioned (whatever tools and database like mango, etc) are indeed working seamlessly. your first sprint or two will therefore have less functionality with a lot of ground work to stage that functionality which will come in handy for your future functionality. your effort for similar new features would of course be less as the team is aware of the less work needed to update the existing environment and database already setup.