[[developer stories vs user stories]]
[[task oreinted]]
[[team have to talk through the process/steps they wil use to deliver the user story which is highly valuable in itself]]
[[less than a days effort]]
[[allows multiple developers to work on user story in parrell rather than linear]]
{{one of the thing we have experienced in teams new to the AgileBI process is that a developer will often move a card from the backlog into in progress and once they have done that the team for some reason assigns an ownership fence around it that means no other developer will work on that story. Even if the developer has nothing else to do or they have a particular set of skills that could deliver a component of that story more effectively.
This comes from the way we are taught at school and during waterfall projects to take ownership of a task and make sure we deliver it.
Ownership means the developer must make sure that the story is delivered within the points assigned and that it meets the acceptance criteria for done done. It doesn’t mean that the developer has to deliver all the effort on their own. }}
{{When starting with a new team that is beginning their AgileBI journey we will often just start by having them define user stories, and then progress to using developer stories after they have a number of sprints under their belt. With this approach we will find that the user stories start off being quiet large and we will see the story move from the backlog to in progress near the beginning of the sprint and then sit in progress for the majority of the sprint until it (hopefully) moves to done as we get close to the end of the sprint.
During daily standup the developer will articulate each day a different component they are working on to progress the user story to completion.
At some stage during the retrospective we will find the team start to discuss the way these story’s sit in in progress for so long and their inability to visually see progress everyday. Also they will mention the difficulty for a developer who has nothing to do to see what is left to do to progress the story and what they can help with.
When we see this we know it’s the perfect time to introduce the developer story concept}}