26153RE: [scrumdevelopment] Break down product backlog problem
- Jan 3, 2008Well, it looks like you've got a typical obstinate, "waterfall" oriented PM, and he is not interested in agile development, and Scrum. Maybe you should just feel a bit sorry for him, being so insulated from better ideas and so convinced that he is right.
I have always said that the rules of Scrum, or any other method, are not so rigid that we must agonise about breaking those rules, but the fact is, when you start doing things that are totally contrary to the method that you are following, then you just cannot be said to be following that method, and you are just moving back to the old-fashioned, tried and failed methods of the past. The regular beat of iterations is a major characteristic of Scrum, and indeed mostother agile approaches, and to disturb that so much is making a nonsense of the claim that your following Scrum.
Date: Fri, 4 Jan 2008 09:47:24 +0800
Subject: RE: [scrumdevelopment] Break down product backlog problemthanks Srinivas. I believe our feature can be broken down. but that PM doesn't want to break it down.that's the problem. he thinks it's a waste of effort to break it down and no value. I think he is usedto waterfall(he is new PM from another company), although I try to convince him from risk and quick feedback aspects. but I failed.
From: scrumdevelopment@ yahoogroups. com [mailto:scrumdevelo pment@yahoogroup s.com] On Behalf Of ext srinivas chillara
Sent: 2008年1月3日 19:04
To: scrumdevelopment@ yahoogroups. com
Subject: Re: [scrumdevelopment] Break down product backlog problemHello Leo,This sort of thinking that, things can't be broken, is mostly muddled thinking.If you are at a liberty to tell me/us what this feature is then mostly I can break it down for you.(contact me offline if you want to: ceezone@yahoo. co.in )One argument you can use is:If you think about developeing any fucntionality (either fresh or an enhancement) , as one codes, progress is made in steps. Some are insignificant, some others more significant and a few, very significant.At every significant step it is advisable to check in the code that "works". There are bound to be atleast a couple of significant (or very significant) steps in a given week, let alone a whole sprint. One can also think about these as fucntional milestones. This milestones can be descibed as break points, and be used to breaking up the stories.Example: Booking a plane ticket online. (from a given list of available flights)Broken intoFirst Sprint1) Single person booking on single leg. (Standard rate, no discount or special fare), on a given dateSecond Sprint:2)Two or more passengers (family) booked at the same time, single leg.3) With special fares includedThird Sprint4) Multiple leg, multiple passengers (no break journey)Fourth sprint.... Break journey allowed..... etc ....so on.....I think this comunity has to develop detailed real world examples.cheerioCheenie
----- Original Message ----
From: "leo.ren@nsn. com" <leo.ren@nsn. com>
To: scrumdevelopment@ yahoogroups. com
Sent: Thursday, 3 January, 2008 2:13:12 PM
Subject: [scrumdevelopment] Break down product backlog problem
I encounter a problem when I convince one project manager when we break down product backlog.
There is a feature, which can not be finished in one sprint, I suggest to break it down and finish
Them within two sprints. But the PM doesn't agree with me, he thinks it's no value to do so. And
He think we can re-schedule this special sprint to twice of one normal sprint duration. I think it's not good.
We should keep the duration of one sprint to be same. But I can not convince him. Can anybody
Help me? Or I'm wrong? Thanks.
Now you can chat without downloading messenger. Click here to know how.
Check our comprehensive Salary Centre Overpaid or Underpaid?
- << Previous post in topic Next post in topic >>