This question does not appear to be about programming within the scope defined in the help center.
Closed 5 years ago.
Improve this questionThe company I work for is currently looking to move from traditional waterfall into Scrum for development. We are in the process of slowly adopting what practices we can without fully making the move (we still have much to learn before we can fully move on over!).
One of the things we want to implement now, before making the ful开发者_StackOverflow社区l switch, is the taskboard. We all feel it's a great tool that can help with development, and help keep those business users off our backs with the "what you doing?" and "how's it going?" questions and meetings.
So with all that said, one thing I've been wondering is can the tasks on the taskboard change? I know you don't want to be changing Stories, but what about tasks within a story? What if a new task came up, or an old task is no longer valid? Can they be added and/or removed mid-sprint (though we're not really using sprints, more like short development cycles).
Thanks!
I know you don't want to be changing Stories, but what about tasks within a story? What if a new task came up, or an old task is no longer valid? Can they be added and/or removed mid-sprint (...).
Yes, they can. During an iteration, a team typically gathers knowledge and gets a better understanding of what has to be done, or not. As a consequence, a team may discover that a task isn't really relevant, that a given Backlog Item requires more work than expected, that an initial estimation is wrong. In such cases, you definitely want to update your Sprint Backlog and the Burndown Chart to stick to the reality and keep what has to be done visible: you really want to know if the iteration is still on track, if you can take one more items, etc.
So, yes, don't hesitate to update, remove, add tasks as soon as you discover it has to be done. And the earlier, the better.
In our team, we use a task board inspired by Scrum and XP from the Trenches from Henrik Kniberg and we have a special location for "unplanned items" as illustrated below:
We like this approach because it makes easy to detect if unplanned items are killing an iteration. And we also "review" such tasks during the retrospective to see how we can improve our planning meeting, our estimations, the way we break down items, etc.
The team commit on user stories, not tasks
It's not a problem to have some tasks changing as you are facing problems or have better implementation ideas.
In fact, it's very rare to finish a sprint with every task 100% "predicted" accurate in the sprint planning meeting.
They can and should change. The board should be updated at least daily.
But Pascal replied to that already - I want to make another point: from experience 'trying to adopt' Agile through small changes won't work. Scrum is a complete framework - by this I mean there is very little in Scrum (I'd say nothing) that can be dropped without doing harm to the process and promoting dysfunction or at least allow dysfunction to continue (wrote about it). Going slowly can be the only way to go in some companies/circumstances, but it has this risk that lingering dysfunctions will blow the process of change/improvement before it can reach its end and yield benefits.
I already like Pascal and Andy's answers so not to repeat.
A usefull alternative is to start a Kanban Board. Henrik Kniberg also has a good 'book' about it, available here: http://blog.crisp.se/henrikkniberg/2009/04/03/1238795520000.html
It allows you to organise your work and be isert some Agile thinking into the company. As Andy said, Scrum is an All-in, if not you will find that 'It doesn't work'.
Why not? Leave the space to team to complete the work the way they would like to do.
Stories are 'contract' between client, product owner and team, therefore it is good to not change, add, remove stories without letting them know. But tasks are only for team.
The team should be able to track the effort the way they need to make it visible.
Questionable is a change of hours the team commited to complete in the sprint, but good scrum master and experienced team is able to self-organize that.
精彩评论