Primary Navigation

RE: [scrumdevelopment] Re: Sprint planning

Yes, it makes sense, but there are a number of different types of dependancy, and often the apparently dependant processes can be developed as if they are not

Message 1 of 14
, Apr 30, 2008

0 Attachment

Yes, it makes sense, but there are a number of different types of dependancy, and often the apparently dependant processes can be developed as if they are not dependant.

For example, one type of dependancy is basically the scenario situation in a Use Case. In this situation the main processing scenario can be developed and left bare of the other scenarios, which can be added later, so they are not tightly coupled scenarios. Where the dependancy is such that one process interfaces with another, and derives data from the oter, then you can break that dependancy and define an interface. You can then create dummy processes that return sufficient data fro the main process to proceed, and plug in those other modules as they become available. An dependancy must be scrutinised to se if the coupling can be loosened. One feature of a good User Story is that is is independant of other User Stories.

The good old fashioned concepts of coupling and cohesion are as relevant and imortant today as they were 30 years ago when I first started writing COBOL programs.

We run into a lot of stories that have dependencies into them. My
first thought was to have the dependency be a separate story from the
original story but what I learned was that incorporating the
dependency into my story made for better use of time and completion.

If story XYZ is #1 on your list and story ABC is a dependency on XYZ.
Then in theory, story ABC is #1 because until ABC is done, you cannot
move on to XyZ.

Under the way we do it now, we make ABC a task under XYZ and if we
have to spend the whole sprint on it, so be it, but we are attacking
the backlog in correct prioritization order.

Does that make sense or am i rambling from being tired heh.

--- In scrumdevelopment@ yahoogroups. com, "Jeff" <ne14mx@...> wrote:
>
> Ahh.. the 'dependency' issue.
>
> I do beleive there are dependencies w/ backlog items that sometimes
cant be
> avoided.
>
> However, I also heard in the scrum training (which touched
minimally on
> software development) that most dependencies can almost always be
removed.
>
> e.g. in your example...
>
> "Be able to edit account info" is fairly broad.
>
> The second one could be TWO backlog items...
>
> "be able to edit certain aspects (?) of an account's invoices, e.g.
set the
> "paid" flag, etc.
>
> "be able to edit account invoices on the account edit screen".
>
> My point is that by splitting up backlog items into finer
granularity, where
> each can meet a "doneness" criteria allows for better parallelism,
and
> improved decoupling of the code.
>
> Also, each backlog item can then be testable by itself.
>
> One thing I have seen, is that backlog "slicing" does
require "architect
> level" or at least fairly senior folks that have a good idea of
what needs
> to be built, and how to build it, to define backlog items
sufficently,
> before the team can commit to backlog items.
>
> Just my 2 cents. I'm new to this also.
>
>
> _____
>
> From: scrumdevelopment@ yahoogroups. com
> [mailto:scrumdevelopment@ yahoogroups. com] On Behalf Of Mark Smeltzer
> Sent: Friday, March 03, 2006 10:03 AM
> To: scrumdevelopment@ yahoogroups. com
> Subject: [scrumdevelopment] Sprint planning
>
>
> Speaking as one who is still very new to Scrum, I have a somewhat
> newbieesque question to ask that has to do with Sprint planning.
I've seen
> in the literature that the highest priority items in the backlog
should be
> those that are most critical to the product's success and that the
riskiest
> of these items should be tackled first. I find that reasoning to be
very
> much in line with common sense.
>
> However, I am having troubles caching out what that means in
practical
> terms. Currently, we are assessing (on a scale of 1 to 10) the
relative
> effort, risk, and need factors of each item in the backlog, as well
as
> inter-item dependencies ( e.g. if story 1 = "be able to edit account
> information" and story 2 = "be able to manipulate a list of the
account's
> invoices on the account edit screen", then story 2 is dependent
upon story
> 1), but it is unclear to me how those values and relationships
should weigh
> in the overall prioritization scheme.
>
> Any suggestions?
>

I see what you are saying about story criteria that is independant of other stories. I think where I misinterpret or am still learning about this process on

Message 2 of 14
, Apr 30, 2008

0 Attachment

I see what you are saying about story criteria that is independant of other stories.

I think where I misinterpret or am still learning about this process on creating better user-centric stories is in what we define as dependencies.

Most of oru dependicies for our projects are usually graphical assets. To finish one story, we need the assets that come from the design dept.

So we either a) make the design of the assets its own story, or we make it a task under our main story which is the project that requires the assets.

In this case, where grahpics are what are needed to finish the product and that asset comes from a different dept , what are your thoughts on proper story creation then ?

Roy Morien <roymorien@...> wrote:

Yes, it makes sense, but there are a number of different types of dependancy, and often the apparently dependant processes can be developed as if they are not dependant.

For example, one type of dependancy is basically the scenario situation in a Use Case. In this situation the main processing scenario can be developed and left bare of the other scenarios, which can be added later, so they are not tightly coupled scenarios. Where the dependancy is such that one process interfaces with another, and derives data from the oter, then you can break that dependancy and define an interface. You can then create dummy processes that return sufficient data fro the main process to proceed, and plug in
those other modules as they become available. An dependancy must be scrutinised to se if the coupling can be loosened. One feature of a good User Story is that is is independant of other User Stories.

The good old fashioned concepts of coupling and cohesion are as relevant and imortant today as they were 30 years ago when I first started writing COBOL programs.

We run into a lot of stories that have dependencies into them. My first thought was to have the dependency be a separate story from the original story but what I learned was that incorporating the dependency into my
story made for better use of time and completion.

If story XYZ is #1 on your list and story ABC is a dependency on XYZ. Then in theory, story ABC is #1 because until ABC is done, you cannot move on to XyZ.

Under the way we do it now, we make ABC a task under XYZ and if we have to spend the whole sprint on it, so be it, but we are attacking the backlog in correct prioritization order.

Does that make sense or am i rambling from being tired heh.

--- In scrumdevelopment@ yahoogroups. com, "Jeff" <ne14mx@...> wrote: > > Ahh.. the 'dependency' issue. > > I do beleive there are dependencies w/ backlog items that sometimes cant be > avoided. > > However, I also heard in the scrum training (which touched minimally on > software development) that most dependencies can almost always be
removed. > > e.g. in your example... > > "Be able to edit account info" is fairly broad. > > The second one could be TWO backlog items... > > "be able to edit certain aspects (?) of an account's invoices, e.g. set the > "paid" flag, etc. > > "be able to edit account invoices on the account edit screen". > > My point is that by splitting up backlog items into finer granularity, where > each can meet a "doneness" criteria allows for better parallelism, and > improved decoupling of the code. > > Also, each backlog item can then be testable by itself. > > One thing I have seen, is that backlog "slicing" does require "architect > level" or at least fairly senior folks that have a good idea of what needs > to be built, and how to build it, to define backlog items sufficently, >
before the team can commit to backlog items. > > Just my 2 cents. I'm new to this also. > > > _____ > > From: scrumdevelopment@ yahoogroups. com > [mailto:scrumdevelopment@ yahoogroups. com] On Behalf Of Mark Smeltzer > Sent: Friday, March 03, 2006 10:03 AM > To: scrumdevelopment@ yahoogroups. com > Subject: [scrumdevelopment] Sprint planning > > > Speaking as one who is still very new to Scrum, I have a somewhat > newbieesque question to ask that has to do with Sprint planning. I've seen > in the literature that the highest priority items in the backlog should be > those that are most critical to the product's success and that the riskiest
> of these items should be tackled first. I find that reasoning to be very > much in line with common sense. > > However, I am having troubles caching out what that means in practical > terms. Currently, we are assessing (on a scale of 1 to 10) the relative > effort, risk, and need factors of each item in the backlog, as well as > inter-item dependencies ( e.g. if story 1 = "be able to edit account > information" and story 2 = "be able to manipulate a list of the account's > invoices on the account edit screen", then story 2 is dependent upon story > 1), but it is unclear to me how those values and relationships should weigh > in the overall prioritization scheme. > > Any suggestions? >

Be a better friend, newshound, and
know-it-all with Yahoo! Mobile. Try it now.

Sharmila D

I have been working with a Scrum team for the core Architecture of the product. We have been working in sprints. However since it is core architecture, we have

Message 3 of 14
, Nov 23, 2009

0 Attachment

I have been working with a Scrum team for the core Architecture of the product. We have been working in sprints. However since it is core architecture, we have different modules for which within the team we have people who have expertise. So after we have planned and estimated in the sprint planning meeting, we often end-up with uneven leveling of work.

Although I completely understand that in the Sprint planning, the team commits. However after the sprint planning we have to work out and find if we have people who are overloaded.

Has anyone encountered this kind of situation?

How do we improve the sprint planning in this case?

We have also proposed competency building but the "expert" area will still remain to some extent.

It's easier to write "the team commits and picks of work" but that's not really the case here.

Any thoughts or ideas?

Gabriel Notari

Hi Sharmila, One thing we try to do on the company I work on is to do not concentrate all work on one particular area or subject within the same person. Since

Message 4 of 14
, Nov 23, 2009

0 Attachment

Hi Sharmila,

One thing we try to do on the company I work on is to do not concentrate all work on one particular area or subject within the same person. Since all individuals are from the same team, we try to spread the knowledge across the team by associating tasks from different subjects to different people. This gives you in short-term a decrease of productivity of course, since people needs to ramp-up on new areas or technologies and this will be reflected somehow (even in product quality, since unexperienced people usually generates more bugs). However, in the mid/long-term this gives the team the benefit of being able to associate tasks in a more flexible manner and this problem tends to disappear. Also, this reduces your risk of being "hostage" (I really dislike this term, but I c)

I have been working with a Scrum team for the core Architecture of the product. We have been working in sprints. However since it is core architecture, we have different modules for which within the team we have people who have expertise. So after we have planned and estimated in the sprint planning meeting, we often end-up with uneven leveling of work.

Although I completely understand that in the Sprint planning, the team commits. However after the sprint planning we have to work out and find if we have people who are overloaded.

Has anyone encountered this kind of situation?

How do we improve the sprint planning in this case?

We have also proposed competency building but the "expert" area will still remain to some extent.

It's easier to write "the team commits and picks of work" but that's not really the case here.

Any thoughts or ideas?

Gabriel Notari

Now with the full answer. Sorry for duplicates. Hi Sharmila, One thing we try to do on the company I work on is to do not concentrate all work on one

Message 5 of 14
, Nov 23, 2009

0 Attachment

Now with the full answer. Sorry for duplicates.

Hi Sharmila,

One thing we try to do on the company I work on is to do not concentrate all work on one particular area or subject within the same person. Since all individuals are from the same team, we try to spread the knowledge across the team by associating tasks from different subjects to different people. This gives you in short-term a decrease of productivity of course, since people needs to ramp-up on new areas or technologies and this will be reflected somehow (even in product quality, since unexperienced people usually generates more bugs). However, in the mid/long-term this gives the team the benefit of being able to associate tasks in a more flexible manner and this problem tends to disappear. Also, this reduces your risk of being "hostage" (I really dislike this term, but I can't find a better one) of a single member, so if he/she became sick, or resigns the position, you have someone who can do the work inside the team. Not sure if this is the answer you were looking for, but it is working on the teams I'm working on.

One thing we try to do on the company I work on is to do not concentrate all work on one particular area or subject within the same person. Since all individuals are from the same team, we try to spread the knowledge across the team by associating tasks from different subjects to different people. This gives you in short-term a decrease of productivity of course, since people needs to ramp-up on new areas or technologies and this will be reflected somehow (even in product quality, since unexperienced people usually generates more bugs). However, in the mid/long-term this gives the team the benefit of being able to associate tasks in a more flexible manner and this problem tends to disappear. Also, this reduces your risk of being "hostage" (I really dislike this term, but I c)

I have been working with a Scrum team for the core Architecture of the product. We have been working in sprints. However since it is core architecture, we have different modules for which within the team we have people who have expertise. So after we have planned and estimated in the sprint planning meeting, we often end-up with uneven leveling of work.

Although I completely understand that in the Sprint planning, the team commits. However after the sprint planning we have to work out and find if we have people who are overloaded.

Has anyone encountered this kind of situation?

How do we improve the sprint planning in this case?

We have also proposed competency building but the "expert" area will still remain to some extent.

It's easier to write "the team commits and picks of work" but that's not really the case here.

Any thoughts or ideas?

JackM

there s a couple things you can do. 1. try take advantage of pair programming which will help you in the long run as this tends to cross-pollinate knowledge ..

Message 6 of 14
, Nov 24, 2009

0 Attachment

there's a couple things you can do.

1. try take advantage of pair programming which will help you in the long run as this tends to cross-pollinate knowledge .. then you'll have fewer silos in the long term.

2. After you plan you say you end up with uneven workload. Well that's not all that bad assuming that all can get done that you planned into the sprint. If someone is loaded beyond their capacity well then you only have one option and that is to pull some stuff off.

If some folks have filler time, then they could pair program with the other loaded developers, they can help write unit tests etc, trust me there's always plenty to go around.

Further to your questions, absolutely, many times after a planning sessions you figure out that there's too much stuff. In this case you negotiate with the PO what to drop

--- In scrumdevelopment@yahoogroups.com, "Sharmila D" <sharmila.patwardhan@...> wrote:
>
> I have been working with a Scrum team for the core Architecture of the product. We have been working in sprints. However since it is core architecture, we have different modules for which within the team we have people who have expertise. So after we have planned and estimated in the sprint planning meeting, we often end-up with uneven leveling of work.
>
> Although I completely understand that in the Sprint planning, the team commits. However after the sprint planning we have to work out and find if we have people who are overloaded.
>
> Has anyone encountered this kind of situation?
>
> How do we improve the sprint planning in this case?
>
> We have also proposed competency building but the "expert" area will still remain to some extent.
>
> It's easier to write "the team commits and picks of work" but that's not really the case here.
>
> Any thoughts or ideas?
>

Mark Levison

Your problem isn t sprint planning, its the silos. Anytime you have silos - i.e. only person that can do something you will have bottlenecks. Whole books are

Message 7 of 14
, Nov 25, 2009

0 Attachment

Your problem isn't sprint planning, its the silos. Anytime you have
silos - i.e. only person that can do something you will have
bottlenecks. Whole books are written on this subject (think Goldratt
and the Theory of Constraints). Scrum tells you to have team members
pull + self assign work - only when they're free to avoid this problem.
Over time it will create a team of generalising specialists.

Congratulations this is one of the key agile problems that everyone finds sooner or later.

I have been working with a Scrum team for the core Architecture of the product. We have been working in sprints. However since it is core architecture, we have different modules for which within the team we have people who have expertise. So after we have planned and estimated in the sprint planning meeting, we often end-up with uneven leveling of work.

Although I completely understand that in the Sprint planning, the team commits. However after the sprint planning we have to work out and find if we have people who are overloaded.

Has anyone encountered this kind of situation?

How do we improve the sprint planning in this case?

We have also proposed competency building but the "expert" area will still remain to some extent.

It's easier to write "the team commits and picks of work" but that's not really the case here.