At the moment we are creating tasks based on (pointed) user stories. We then link the tasks to the user story in TFS and move them across the kanban board. Does this sound like a common approach? also how do we report on the tasks? Our velocity doesn’t look good as the tasks aren’t pointed. we might complete 2 out of 3 tasks in a sprint so how do we report on this?
2
Your approach of splitting stories into tasks and moving those tasks across the board is very standard fare in Scrum.
There should be no need to report on the task-level in TFS, because tasks don’t create value to the business. It is the completed stories that create value to the business.
If a story isn’t fully completed by the end of a sprint, then that story must go back to the backlog to be planned again in a future sprint (possibly the next one, depending on the priorities).
If your team has trouble completing most of the stories, then there are a couple possible reasons:
- The stories are simply too big to complete in a sprint. If that is the case, then your stories are really epics that must be split into smaller stories.
- There is insufficient focus on completing the stories. The team should strive to complete at least the topmost few stories.
- The team is seriously over-committing themselves. If the team is consistently too optimistic about what they can accomplish (possibly with added pressure from the business), the scrum master should step in and let the team commit to a realistic number of points, based on the historic velocity. Actually making true on the commitment is a very good boost for morale.
Ok. i think we’ve got a solution with the user stories. I can understand how to break them down further now so that they still have value to the business. Part of our problem is tackling too much work at once. This means we have very little velocity for a few sprints and then it jumps massively when everyones work is complete. Our approach is to move tasks across the board that are all linked to a user story. We create the user story and tasks in TFS, the tasks are linked as children. If the business needs to see progress in every sprint then you need to ensure your stories are manageable and maybe that the whole team works on a story to try and complete it in a sprint. if things are less relaxed then maybe you can let a user story run as long as the business can see the progress of the tasks. Again its all about how it works for you. I think a key question is what the business needs to see and how often. Also, on the Kanban we list the task and the user story that it relates to on the same card. I’m also thinking that once all tasks are complete in terms of Dev that the actual user story card is placed in the testing lane and the linked task cards are removed from the board. If the product owner loads up the user story in TFS they will see the status of all the linked tasks. For anyone interested, the type of work item we use in TFS for a user story is “Functional”. When we want to add a task we load the user story and add child tasks as necessary.