Comments on: Scrum 101 – taking it from theory to practice http://www.fronde.com/blog/2009/05/scrum-101-taking-it-from-theory-to-practice/ Fronde, The Future of Business Tue, 01 Jun 2010 10:40:30 +1200 http://wordpress.org/?v=2.8.5 hourly 1 By: Autumn/May Blog Summary « Fronde Blog http://www.fronde.com/blog/2009/05/scrum-101-taking-it-from-theory-to-practice/comment-page-1/#comment-183 Autumn/May Blog Summary « Fronde Blog Thu, 28 May 2009 07:05:56 +0000 http://www.fronde.com/blog/?p=273#comment-183 [...] @ Fronde. Also on the blogs agile methodologies continue to create interest and a little heat. In Scrum 101 - taking it from theory to practice and The “Agile landscape” presentation, and how it went down at PMI Carolyn Sanders gives us an [...] [...] @ Fronde. Also on the blogs agile methodologies continue to create interest and a little heat. In Scrum 101 – taking it from theory to practice and The “Agile landscape” presentation, and how it went down at PMI Carolyn Sanders gives us an [...]

]]> By: Carolyn Sanders http://www.fronde.com/blog/2009/05/scrum-101-taking-it-from-theory-to-practice/comment-page-1/#comment-129 Carolyn Sanders Mon, 18 May 2009 05:49:36 +0000 http://www.fronde.com/blog/?p=273#comment-129 Hi Tony, Aieee! Thank you for that. I'll fix the numbers before I dare use that slide again. Cheers! Hi Tony,

Aieee! Thank you for that. I’ll fix the numbers before I dare use that slide again.

Cheers!

]]> By: Tony Sargent http://www.fronde.com/blog/2009/05/scrum-101-taking-it-from-theory-to-practice/comment-page-1/#comment-128 Tony Sargent Mon, 18 May 2009 04:44:41 +0000 http://www.fronde.com/blog/?p=273#comment-128 Hi Carolyn, I enjoyed your presentation - it was interesting and refreshing, and gave me some ideas to try in the future. I was particularly taken with your suggestion for how to arrive at estimates for items in the product backlog viz. the Fibonacci series or Planning Poker cards. Using this technique sounds like a good way of short-circuiting something that can otherwise take weeks. One small point, I think there's a 'bugette' in the Fibonacci series shown in the slide - the number after 8 should be 13, with the values following that adjusted in synch. :-) Cheers Tony Sargent Hi Carolyn, I enjoyed your presentation – it was interesting and refreshing, and gave me some ideas to try in the future. I was particularly taken with your suggestion for how to arrive at estimates for items in the product backlog viz. the Fibonacci series or Planning Poker cards. Using this technique sounds like a good way of short-circuiting something that can otherwise take weeks. One small point, I think there’s a ‘bugette’ in the Fibonacci series shown in the slide – the number after 8 should be 13, with the values following that adjusted in synch. :-)

Cheers

Tony Sargent

]]> By: Carolyn Sanders http://www.fronde.com/blog/2009/05/scrum-101-taking-it-from-theory-to-practice/comment-page-1/#comment-108 Carolyn Sanders Thu, 14 May 2009 02:18:31 +0000 http://www.fronde.com/blog/?p=273#comment-108 See above :-) See above :-)

]]> By: Carolyn Sanders http://www.fronde.com/blog/2009/05/scrum-101-taking-it-from-theory-to-practice/comment-page-1/#comment-107 Carolyn Sanders Thu, 14 May 2009 02:18:16 +0000 http://www.fronde.com/blog/?p=273#comment-107 Hi Inbal, Thank you! <strong>1. What do you do with the notes of completed stories / tasks after the sprint is over. Do you throw them to the rubbish? Or keep them for something?</strong> We keep them - we need them for the Retrospective. Once the project and Retrospective is over, I usually hang on to them for a while for sentimental reasons :-) and then throw them out. We use MOSS sites to keep all our project documents and backlog lists, and those stick around. <strong>2. (also asked in the evening): say we estimated a story in 8 days and now we break it down to tasks and it’s actually looking more like 20 days. I think this scenario should be quite common… What do we do? What did you do in your project that was fixed price fixed time? fixed scope? </strong> First, our project was not fixed scope. The client had a fixed budget and therefore pretty fixed schedule, and they wanted high quality, so we agreed that if push came to shove, we'd trade off scope to meet those other constraints. (That's not part of Scrum, it's part of Agile Project Management from Rob Thomsett). But Scrum is pretty clear in this situation: when a task blows out when you take a closer look at it, first the Team need to look at it together and come up with some options - eg drop some other tasks, or defer this whole task to another Sprint, or don't do it at all. Then the Team needs to work with the Product Owner to make a decision, by helping them understand all the consequences. One or two tasks blowing out will happen on every project. If it happens on a lot of tasks, it might be something to discuss in the Retrospective. <strong>3. As the project progresses the backlog can grow with tasks we haven’t thought about and with bugs we discovered after a sprint was over. So we get ‘heavier’ and heavier. Do you prepare ‘buffers’ for that?</strong> Again it's about tradeoffs. If the project has a fixed budget or deadline, and you add new items to the product backlog, the product owner needs to decide whether they should displace existing items, or go in a later project (and not in this one). Otherwise, maybe you need more sprints - and again the team should re-estimate the product backlog, re-estimate how many sprints are now required, and work out a decision with the product owner. The key is that you don't change what's in a sprint while you're doing it, but the product owner has the mandate to change what's in future sprints at any time. Hi Inbal,

Thank you!

1. What do you do with the notes of completed stories / tasks after the sprint is over. Do you throw them to the rubbish? Or keep them for something?

We keep them – we need them for the Retrospective. Once the project and Retrospective is over, I usually hang on to them for a while for sentimental reasons :-) and then throw them out. We use MOSS sites to keep all our project documents and backlog lists, and those stick around.

2. (also asked in the evening): say we estimated a story in 8 days and now we break it down to tasks and it’s actually looking more like 20 days. I think this scenario should be quite common… What do we do? What did you do in your project that was fixed price fixed time? fixed scope?

First, our project was not fixed scope. The client had a fixed budget and therefore pretty fixed schedule, and they wanted high quality, so we agreed that if push came to shove, we’d trade off scope to meet those other constraints. (That’s not part of Scrum, it’s part of Agile Project Management from Rob Thomsett).

But Scrum is pretty clear in this situation: when a task blows out when you take a closer look at it, first the Team need to look at it together and come up with some options – eg drop some other tasks, or defer this whole task to another Sprint, or don’t do it at all. Then the Team needs to work with the Product Owner to make a decision, by helping them understand all the consequences.

One or two tasks blowing out will happen on every project. If it happens on a lot of tasks, it might be something to discuss in the Retrospective.

3. As the project progresses the backlog can grow with tasks we haven’t thought about and with bugs we discovered after a sprint was over. So we get ‘heavier’ and heavier. Do you prepare ‘buffers’ for that?

Again it’s about tradeoffs. If the project has a fixed budget or deadline, and you add new items to the product backlog, the product owner needs to decide whether they should displace existing items, or go in a later project (and not in this one). Otherwise, maybe you need more sprints – and again the team should re-estimate the product backlog, re-estimate how many sprints are now required, and work out a decision with the product owner. The key is that you don’t change what’s in a sprint while you’re doing it, but the product owner has the mandate to change what’s in future sprints at any time.

]]> By: Inbal http://www.fronde.com/blog/2009/05/scrum-101-taking-it-from-theory-to-practice/comment-page-1/#comment-97 Inbal Tue, 12 May 2009 21:04:12 +0000 http://www.fronde.com/blog/?p=273#comment-97 Oh, and the last one (for now) - where will you publish the notes from the talk? Oh, and the last one (for now) – where will you publish the notes from the talk?

]]> By: Inbal http://www.fronde.com/blog/2009/05/scrum-101-taking-it-from-theory-to-practice/comment-page-1/#comment-96 Inbal Tue, 12 May 2009 21:03:28 +0000 http://www.fronde.com/blog/?p=273#comment-96 Your talk was excellent and interesting, with a lot to take home. Well done! A few questions from a newbe: 1. What do you do with the notes of completed stories / tasks after the sprint is over. Do you throw them to the rubbish? Or keep them for something? 2. (also asked in the evening): say we estimated a story in 8 days and now we break it down to tasks and it's actually looking more like 20 days. I think this scenario should be quite common... What do we do? What did you do in your project that was fixed price fixed time? fixed scope? 3. As the project progresses the backlog can grow with tasks we haven't thought about and with bugs we discovered after a sprint was over. So we get 'heavier' and heavier. Do you prepare 'buffers' for that? Many thanks, Inbal. Your talk was excellent and interesting, with a lot to take home. Well done!
A few questions from a newbe:
1. What do you do with the notes of completed stories / tasks after the sprint is over. Do you throw them to the rubbish? Or keep them for something?
2. (also asked in the evening): say we estimated a story in 8 days and now we break it down to tasks and it’s actually looking more like 20 days. I think this scenario should be quite common… What do we do? What did you do in your project that was fixed price fixed time? fixed scope?
3. As the project progresses the backlog can grow with tasks we haven’t thought about and with bugs we discovered after a sprint was over. So we get ‘heavier’ and heavier. Do you prepare ‘buffers’ for that?

Many thanks,
Inbal.

]]>