6

The 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 full 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!

Jason L.
  • 2,464
  • 1
  • 23
  • 41
  • This seems like good candidate for http://area51.stackexchange.com/proposals/6922/software-engineering which will enter private beta soon... – Paweł Dyda Sep 18 '10 at 17:06
  • 4
    I'm voting to close this question as off-topic because it is not about programming. – Vadim Kotov Nov 02 '17 at 08:06

5 Answers5

10

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:

Scrum Task Board

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.

Pascal Thivent
  • 562,542
  • 136
  • 1,062
  • 1,124
  • Thank you very much for your insight Pascal. That picture is really useful, and I quite like the idea of having a designated area for "Unplanned Items". Thought our board is not really big enough for another section, I'm thinking we can utilize a different color sticky note (as we only use two colors now - Green for story tasks and orange for defects). – Jason L. Sep 18 '10 at 21:26
3

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.

  • Thank you very much for this. The "The team commit on user stories, not tasks" is something that seems like it's going to be extremely useful for us to remember! – Jason L. Sep 18 '10 at 21:24
2

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.

Andy
  • 644
  • 4
  • 9
1

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'.

Rudi
  • 3,124
  • 26
  • 35
1

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.

Dusan Kocurek
  • 445
  • 3
  • 8
  • 22