In lean/agile software development, work - whether concerning a single product/project/other activity, or multiple ones - is generally preferred to be assigned to a team instead of assigning a single person to work on multiple activities in parallel.

Below is a copy-paste from section 2.3.10 of my Ph.D. draft (http://www.soberit.hut.fi/jvahanii/docu ... ddraft.zip) discussing the same issue:

2.3.10 Portfolio management as time management in daily work

The discovered literature on agile software development in general recommends that all of the team’s work, whether related to the ongoing development effort or not, should be included in the sprint backlog, and that a single person should have a single sprint backlog to pull tasks from at any given time (Larman & Vodde 2010). However, when multiple assignments must be made, the literature seems to be strongly in favor of assigning stabile teams to pull work items from multiple backlogs, as opposed to assigning people on multiple teams (Tengshe & Noble 2007, Larman & Vodde 2008). And according to the discovered experience reports, when it comes to multiple assignments, both modes of operation are commonly applied in practice (Hodgkins & Hohmann 2007, Laanti 2008, Tengshe & Noble 2007).

...

Chapter 9 (Agile Development
Portfolio Management) from the book Towards Agile Product and Portfolio Management (http://www.soberit.hut.fi/sprg/projects ... gement.pdf) discusses the same issue - see especially section 9.2:

To support teams and individuals who for one reason or another have to work on multiple concurrent development activities to properly manage their backlog and adhere to agile/lean principles, you need what we call floating backlogs. The backlog is "floating", because it is not related to any specific product/business area, or even a time horizon. Instead, it refers to a prioritized list of stories merged from the product/release backlogs of multiple product/business areas that a particular team (or individual) is responsible for at a particular moment in time. The priorities of the work items as well as the intended resource spending per activity have been negotiated and agreed upon by the product owners responsible for the product/business areas in question.

...

However, supporting this cannot be done in the current (2.0.4) version of Agilefant, since projects can include items from a single product only, and likewise, iterations can contain items from their "parent" project.

In my mind, projects should be able to contain items from multiple products. The same goes for iterations, and in addition, they should be able to contain items from multiple projects.

Any thoughts at this point? Also, if you view this as something that would be useful to be changed, I'd like to know about it under this topic - a short post will do!

More info on how I think Agilefant should be modified to better accommodate this need coming up when I get the chance to spend a bit more time on writing about it...

P.S. Check out
real-team-support-t16.html for the initial request concerning this feature. However, the idea is not new as such, we've been thinking about it for a couple of years now.

Hi,
this is really interesting, as it would definitively solve my main concern with Agilefant !

Your way of solving these issues seems very appealing to me. I'm eagerly waiting your detailed description on what you're precisely thinking about... Then I will add my grain of salt ;-)

Hi,

I also find this feature interresting as it's my typical of my case. I have multiple product in parallel with multiple projects going on at the same time.

In this regard I (ab)use of the "daily work/load" page. Could it be possible (usefull in the case you described) to have the stories and tasks grouped per project (or product)?

Thanks for the update.

Francois.

The change will affect quite many places in the system, and certainly daily work page as well. However, the exact changes needed (for example, the grouping you describe) are quite hard for me to predict at this point... let's see what the situation is as we are longer ahead in development.

It would be great if you could place a story/task belonging to one project in the iteration of another project. In my case I have on Product containing two projects and sometimes one project/team need to help the other bu doing a task or sometimes a story..

I'd keep a task within a story, but allow for assigning a story into the iteration of another project. What do you think?

Also, should stories be allowed to be assigned to multiple iterations? Why or why not? There are pros and cons to this...

Hello,

just a thought from our current development setup - we have multiple teams and we need to split stories between iterations and teams (I think this could be done via the story tree and having sub-stories for each iteration or team) - but sometimes we would also like to split tasks between teams / iterations, example:

- graphical design team has to do screen prototypes for the new features in Sprint 1,
- development team builds the feature in sprint 2,
- while the sysadmin team also in sprint 2 gets the server upgrade in place so that the new feature can go live.


Is this a common scenario for bigger projects? Would it make sense then, to allow splitting tasks for the same story over multiple teams / iterations?

regards,
fivebarn

Probably a quite common scenario, in bigger projects as well as smaller ones. Still, it is a bit of an anti-pattern, at least looking from a lean/agile/scrum angle:
- tasks should be small; a task that you describe above does not look like a small one
- ideally, a team should be able to do a story completely on its own
- ideally, teams should be cross-functional (as opposed to graphics, dev and sysadmin silos)

Thus, I'd rather wish that Agilefant would not support modeling such behaviour. Instead, splitting stories using the tree - like you suggested - is how I would model the situation you describe. The parent story would not be Done until all the teams have completed their parts.

How does this sound? Yes, a bit agilist response, I know ... but at least it helps in defining the boundaries of new features :-)

(FYI, we've just deciced to call these kinds of iterations 'standalone iterations'...)