Loading ...
Sorry, an error occurred while loading the content.

Developers on multiple projects

Expand Messages
  • bmwpapa
    Here s an example scenario, based on real-world situations, for your feedback... Company A is a small company with 5 projects, and 10 developers. Developers
    Message 1 of 13 , Jan 1, 2010
    • 0 Attachment
      Here's an example scenario, based on real-world situations, for your feedback...

      Company A is a small company with 5 projects, and 10 developers.

      Developers work on multiple projects. This is for various reasons (senior developers contribute their advanced skills and domain knowledge across multiple projects, other developers cross-train for interchangeability, small companies can't afford dedicated teams on each project, etc.).

      If Joe Developer works on 3 projects, he has to track/attend 3 of everything (sprints, stand-ups, planning, review, retrospective). He has to keep track of all his work across all 3 projects. Depending on the situation, he might work on projects in priority order (one project at a time), or he might work on his tasks in priority order (jumping from one project to another).

      [Q:] What is your experience with this? I'm sure it's preferred to have developers/teams dedicated to a single project, but I'm curious how common this scenario has been in your experience and how you've handled it. Should the sprints be aligned or staggered?

      [Q:] What agile tools would you recommend overall for this scenario? I prefer tools that are free/cheap, simple/intuitive, fast/responsive, with potential integration with third-party defect tracking, wiki pages, etc.

      I've researched some nice agile tools that provide easy user story specification with drag-n-drop prioritization, easy drag-n-drop sprint planning, task breakdown, storyboard drag-n-drop, reporting, etc. BUT... tools that manage multiple projects, and enable developers to see their tasks across multiple projects, seem to cost more and have increased complexity.

      In summary, I want to learn the best way to manage this situation (developers on multiple projects), and I want to find cost-effective, simple tools to help the team be most productive when dedicated teams are not an option.
    • Andre
      Having developers on multiple projects is a very common thing. However, it is the wrong thing...assuming in particular that the projects are not related. If
      Message 2 of 13 , Jan 1, 2010
      • 0 Attachment
        Having developers on multiple projects is a very common thing. However, it is the wrong thing...assuming in particular that the projects are not related. If the solutions have to integrate eventually, then it makes more sense...but in that case, I'd use the developers in a different capacity. More leadership and guidance and less actual coding.

        If the projects are unrelated, and you have developers across multiple projects, you'll have to stagger them. Imagine developer A having to attend 3 sprint planning sessions in one day, 3 retrospectives, 3 standups in one day. I tried that once with 4 projects...yeah it sucked. Developers on the teams were doing nothing but attending meetings. Their first impression of Scrum was "meeting hell". Plus, you can only be in one place at once.

        If the projects have to integrate, the sprints should sync up, as the goal is potentially shippable software...and you can't ship unless you integrate.

        Either way, it is bad to have developers on more than one..."maybe" two projects. The cost of context switching is too high. I know it sounds impossible to have developers on only one project, but if you make it happen, you will not regret it. It's just scary because we've been trained that "multi-tasking is good". That is a big fat lie.

        As far as tools...I'm sorry to say this, but I think you best best is index cards, post-its, white-board, excel, etc. IF your teams are co-located. If the team members are geographically dispersed, it's best to get something. In that case, you'll have to get something more complex, like MS Project...okay JUST KIDDING about that one. Seriously, something like Rally, VersionOne, etc. There will be a learning curve though...

        Thanks,

        Andre Simones

        --- In scrumdevelopment@yahoogroups.com, "bmwpapa" <bmwpapa@...> wrote:
        >
        > Here's an example scenario, based on real-world situations, for your feedback...
        >
        > Company A is a small company with 5 projects, and 10 developers.
        >
        > Developers work on multiple projects. This is for various reasons (senior developers contribute their advanced skills and domain knowledge across multiple projects, other developers cross-train for interchangeability, small companies can't afford dedicated teams on each project, etc.).
        >
        > If Joe Developer works on 3 projects, he has to track/attend 3 of everything (sprints, stand-ups, planning, review, retrospective). He has to keep track of all his work across all 3 projects. Depending on the situation, he might work on projects in priority order (one project at a time), or he might work on his tasks in priority order (jumping from one project to another).
        >
        > [Q:] What is your experience with this? I'm sure it's preferred to have developers/teams dedicated to a single project, but I'm curious how common this scenario has been in your experience and how you've handled it. Should the sprints be aligned or staggered?
        >
        > [Q:] What agile tools would you recommend overall for this scenario? I prefer tools that are free/cheap, simple/intuitive, fast/responsive, with potential integration with third-party defect tracking, wiki pages, etc.
        >
        > I've researched some nice agile tools that provide easy user story specification with drag-n-drop prioritization, easy drag-n-drop sprint planning, task breakdown, storyboard drag-n-drop, reporting, etc. BUT... tools that manage multiple projects, and enable developers to see their tasks across multiple projects, seem to cost more and have increased complexity.
        >
        > In summary, I want to learn the best way to manage this situation (developers on multiple projects), and I want to find cost-effective, simple tools to help the team be most productive when dedicated teams are not an option.
        >
      • Elizabeth V Woodward
        I was brought in to help a smaller company a while back… What I found was that the teams were made up of some really amazingly talented people… The biggest
        Message 3 of 13 , Jan 1, 2010
        • 0 Attachment
          I was brought in to help a smaller company a while back… What I found was that the teams were made up of some really amazingly talented people… The biggest problem was that they were constantly being interrupted when working on one thing to work on something else. Along with the multiple projects, there were multiple contacts who could shift the team’s attention…project managers for each project on the client side, project managers for each project on the company’s side, the CEO of the company, the CIO, etc. Not good.

          Because it was a small company, having the entire team dedicated to one project would not have worked. There were lulls in activities where the client was reviewing information with subject matter experts or gathering data for the project. During that time, the team had cycles to work on other projects. Additionally, there really were time-sensitive, critical work items (developing a time-sensitive proposal with some initial modeling for a potential client, for example) that needed to be done in parallel with current project work.  It wouldn’t make sense to wait until the end of one project to work on the proposal, for example.

          What we did was set up a backlog of all of the work for the whole team, owned and prioritized by one person. The CEO determined who would serve as that Product Owner. That Product Owner took input from the different project contacts, the Team, etc, and—based on knowledge of the projects, technical constraints, business impact, the team’s capabilities/input and info they provided on the cost of context switching—the PO was ultimately responsible for the order/prioritization of work items in the backlog. This helped to eliminate the thrashing we were seeing. It also made visible problems with too many projects in play at a given time. Using velocity and looking at the size of the work items, everyone had a much more realistic picture of what user stories and other work items could be accomplished. Engaging clients for the reviews and planning ensured that we stayed in alignment with clients' expectations.

          The whole team (7 people) participated in ONE Daily Scrum, so everyone knew what everyone else was working on. The team answered the three questions, focused on discussing dependencies they had on each other, let other people know when they needed help, discussed potential blockers, etc. We were able to much more quickly identify and address issues. We did not have separate Daily Scrums depending on which people were working on which projects during that Sprint. Everyone was on the same Sprint cycle. We did not have a separate planning meeting for each project with user stories that would be addressed that Sprint or separate retrospectives for each project. The Team planned and reflected together. However, we did have separate demos/reviews with the appropriate stakeholders for the different projects.

          -elizabeth


          > Please respond to scrumdevelopment

          >

          >  

          > Here's an example scenario, based on real-world situations, for your
          > feedback...
          >
          > Company A is a small company with 5 projects, and 10 developers.
          >
          > Developers work on multiple projects. This is for various reasons
          > (senior developers contribute their advanced skills and domain
          > knowledge across multiple projects, other developers cross-train for
          > interchangeability, small companies can't afford dedicated teams on
          > each project, etc.).
          >
          > If Joe Developer works on 3 projects, he has to track/attend 3 of
          > everything (sprints, stand-ups, planning, review, retrospective).
          He
          > has to keep track of all his work across all 3 projects. Depending
          > on the situation, he might work on projects in priority order (one
          > project at a time), or he might work on his tasks in priority order
          > (jumping from one project to another).
          >
          > [Q:] What is your experience with this? I'm sure it's preferred to
          > have developers/teams dedicated to a single project, but I'm curious
          > how common this scenario has been in your experience and how you've
          > handled it. Should the sprints be aligned or staggered?
          >
          > [Q:] What agile tools would you recommend overall for this scenario?
          > I prefer tools that are free/cheap, simple/intuitive, fast/
          > responsive, with potential integration with third-party defect
          > tracking, wiki pages, etc.
          >
          > I've researched some nice agile tools that provide easy user story
          > specification with drag-n-drop prioritization, easy drag-n-drop
          > sprint planning, task breakdown, storyboard drag-n-drop, reporting,
          > etc. BUT... tools that manage multiple projects, and enable
          > developers to see their tasks across multiple projects, seem to cost
          > more and have increased complexity.
          >
          > In summary, I want to learn the best way to manage this situation
          > (developers on multiple projects), and I want to find cost-
          > effective, simple tools to help the team be most productive when
          > dedicated teams are not an option.
        • Maurice le Rutte
          Why is it that people want to be paid for what they create, but then don t want to pay for stuff others made but still demand it to do everything including
          Message 4 of 13 , Jan 2, 2010
          • 0 Attachment
            Why is it that people want to be paid for what they create, but then don't want to pay for stuff others made but still demand it to do everything including feeding the cat?

            Maurice.

            bmwpapa schreef:
             


            [Q:] What agile tools would you recommend overall for this scenario? I prefer tools that are free/cheap, simple/intuitive, fast/responsive, with potential integration with third-party defect tracking, wiki pages, etc.



            -- 
            http://www.scrummaster.nl / http://twitter.com/scrumnl
          • Johanna Rothman
            Elizabeth, I ve had good results with the approach you describe. Did you use kanban (cards on the wall) to make this happen? bmwpapa, your organization needs
            Message 5 of 13 , Jan 2, 2010
            • 0 Attachment
              Elizabeth,

              I've had good results with the approach you describe. Did you use kanban (cards on the wall) to make this happen?

              bmwpapa, your organization needs to start managing the project portfolio. Especially in small organizations, it's quite common for the number of project to outweigh the number of developers (project staff of all stripes). 

              I just worked with a small organization who sounds like your description. They moved to one-week iterations, with a few people on each staffed project, and each week (or 2) re-evaluated the project portfolio to see which projects to staff now. 

              Right now, you have partial commitment to all the projects, with the result that all are slowing down. I bet there are a bunch of defects being inserted and not caught because of the multitasking in people's brains. 

              I have much of the preface to my book here: 

              Daniel just wrote a nice description here: http://praglife.com/

              A tool is not what you need. You need decisions about which projects to staff *for now* and which ones to postpone. Or, as Elizabeth says, rank order all the features, regardless of project, and make the team work together to work on one backlog, composed of whatever, but the key is that you don't have a lot of work in progress.

              Johanna


              On Jan 1, 2010, at 10:18 PM, Elizabeth V Woodward wrote:

               


              I was brought in to help a smaller company a while back… What I found was that the teams were made up of some really amazingly talented people… The biggest problem was that they were constantly being interrupted when working on one thing to work on something else. Along with the multiple projects, there were multiple contacts who could shift the team’s attention…project managers for each project on the client side, project managers for each project on the company’s side, the CEO of the company, the CIO, etc. Not good.

              Because it was a small company, having the entire team dedicated to one project would not have worked. There were lulls in activities where the client was reviewing information with subject matter experts or gathering data for the project. During that time, the team had cycles to work on other projects. Additionally, there really were time-sensitive, critical work items (developing a time-sensitive proposal with some initial modeling for a potential client, for example) that needed to be done in parallel with current project work.  It wouldn’t make sense to wait until the end of one project to work on the proposal, for example.

              What we did was set up a backlog of all of the work for the whole team, owned and prioritized by one person. The CEO determined who would serve as that Product Owner. That Product Owner took input from the different project contacts, the Team, etc, and—based on knowledge of the projects, technical constraints, business impact, the team’s capabilities/ input and info they provided on the cost of context switching—the PO was ultimately responsible for the order/prioritizatio n of work items in the backlog. This helped to eliminate the thrashing we were seeing. It also made visible problems with too many projects in play at a given time. Using velocity and looking at the size of the work items, everyone had a much more realistic picture of what user stories and other work items could be accomplished. Engaging clients for the reviews and planning ensured that we stayed in alignment with clients' expectations.

              The whole team (7 people) participated in ONE Daily Scrum, so everyone knew what everyone else was working on. The team answered the three questions, focused on discussing dependencies they had on each other, let other people know when they needed help, discussed potential blockers, etc. We were able to much more quickly identify and address issues. We did not have separate Daily Scrums depending on which people were working on which projects during that Sprint. Everyone was on the same Sprint cycle. We did not have a separate planning meeting for each project with user stories that would be addressed that Sprint or separate retrospectives for each project. The Team planned and reflected together. However, we did have separate demos/reviews with the appropriate stakeholders for the different projects.

              -elizabeth


              > Please respond to scrumdevelopment

              >
              >  

              > Here's an example scenario, based on real-world situations, for your
              > feedback...
              >
              > Company A is a small company with 5 projects, and 10 developers.
              >
              > Developers work on multiple projects. This is for various reasons
              > (senior developers contribute their advanced skills and domain
              > knowledge across multiple projects, other developers cross-train for
              > interchangeability, small companies can't afford dedicated teams on
              > each project, etc.).
              >
              > If Joe Developer works on 3 projects, he has to track/attend 3 of
              > everything (sprints, stand-ups, planning, review, retrospective) . He
              > has to keep track of all his work across all 3 projects. Depending
              > on the situation, he might work on projects in priority order (one
              > project at a time), or he might work on his tasks in priority order
              > (jumping from one project to another).
              >
              > [Q:] What is your experience with this? I'm sure it's preferred to
              > have developers/teams dedicated to a single project, but I'm curious
              > how common this scenario has been in your experience and how you've
              > handled it. Should the sprints be aligned or staggered?
              >
              > [Q:] What agile tools would you recommend overall for this scenario?
              > I prefer tools that are free/cheap, simple/intuitive, fast/
              > responsive, with potential integration with third-party defect
              > tracking, wiki pages, etc.
              >
              > I've researched some nice agile tools that provide easy user story
              > specification with drag-n-drop prioritization, easy drag-n-drop
              > sprint planning, task breakdown, storyboard drag-n-drop, reporting,
              > etc. BUT... tools that manage multiple projects, and enable
              > developers to see their tasks across multiple projects, seem to cost
              > more and have increased complexity.
              >
              > In summary, I want to learn the best way to manage this situation
              > (developers on multiple projects), and I want to find cost-
              > effective, simple tools to help the team be most productive when
              > dedicated teams are not an option.



              --

              Rothman Consulting Group, Inc.     781-641-4046

              Speaker, Author, Consultant - Managing Product Development

              ==========================================

              http://www.ayeconference.com, Nov 7-11, 2010

              New: Manage Your Project Portfolio: Increase Your Capacity and Finish More Projects







            • bmwpapa
              Thanks Elizabeth. If I read you correctly, you seem to describe a single backlog, managed by a single PO, with ONE team, across multiple projects. This
              Message 6 of 13 , Jan 2, 2010
              • 0 Attachment
                Thanks Elizabeth. If I read you correctly, you seem to describe a single backlog, managed by a single PO, with ONE team, across multiple projects.

                This appears to be more story/task-centric, rather than project/release-centric - i.e. work on stories/tasks in order of priority, regardless of which project/release it's for. But, then, how do you track your release burndown, velocity, and goals/progress for individual projects? Each project should be release-able after each sprint, but each sprint tracks multiple projects. Unless I'm missing something, this approach seems to cloud the bigger picture.

                In response to other posts...

                Andre seems to suggest that developers on multiple projects is plain wrong. I understand it's not preferred, but I'm not convinced it's always avoidable.

                Maurice seems to think that I want "everything", but I'm willing to pay "nothing". However, I'm really just stating the obvious preference for cost-effectiveness. I want the biggest bang for the buck. Who doesn't?

                I'm still interested to hear more real-world experiences...


                --- In scrumdevelopment@yahoogroups.com, Elizabeth V Woodward <evwoodwa@...> wrote:
                >
                > I was brought in to help a smaller company a while back… What I found was
                > that the teams were made up of some really amazingly talented people… The
                > biggest problem was that they were constantly being interrupted when
                > working on one thing to work on something else. Along with the multiple
                > projects, there were multiple contacts who could shift the team’s
                > attention…project managers for each project on the client side, project
                > managers for each project on the company’s side, the CEO of the company,
                > the CIO, etc. Not good.
                >
                > Because it was a small company, having the entire team dedicated to one
                > project would not have worked. There were lulls in activities where the
                > client was reviewing information with subject matter experts or gathering
                > data for the project. During that time, the team had cycles to work on
                > other projects. Additionally, there really were time-sensitive, critical
                > work items (developing a time-sensitive proposal with some initial
                > modeling for a potential client, for example) that needed to be done in
                > parallel with current project work. It wouldn’t make sense to wait until
                > the end of one project to work on the proposal, for example.
                >
                > What we did was set up a backlog of all of the work for the whole team,
                > owned and prioritized by one person. The CEO determined who would serve as
                > that Product Owner. That Product Owner took input from the different
                > project contacts, the Team, etc, andâ€"based on knowledge of the projects,
                > technical constraints, business impact, the team’s capabilities/input and
                > info they provided on the cost of context switchingâ€"the PO was ultimately
                > responsible for the order/prioritization of work items in the backlog.
                > This helped to eliminate the thrashing we were seeing. It also made
                > visible problems with too many projects in play at a given time. Using
                > velocity and looking at the size of the work items, everyone had a much
                > more realistic picture of what user stories and other work items could be
                > accomplished. Engaging clients for the reviews and planning ensured that
                > we stayed in alignment with clients' expectations.
                > The whole team (7 people) participated in ONE Daily Scrum, so everyone
                > knew what everyone else was working on. The team answered the three
                > questions, focused on discussing dependencies they had on each other, let
                > other people know when they needed help, discussed potential blockers,
                > etc. We were able to much more quickly identify and address issues. We did
                > not have separate Daily Scrums depending on which people were working on
                > which projects during that Sprint. Everyone was on the same Sprint cycle.
                > We did not have a separate planning meeting for each project with user
                > stories that would be addressed that Sprint or separate retrospectives for
                > each project. The Team planned and reflected together. However, we did
                > have separate demos/reviews with the appropriate stakeholders for the
                > different projects.
                > -elizabeth
                >
                > > Please respond to scrumdevelopment
                > >
                > >
                > > Here's an example scenario, based on real-world situations, for your
                > > feedback...
                > >
                > > Company A is a small company with 5 projects, and 10 developers.
                > >
                > > Developers work on multiple projects. This is for various reasons
                > > (senior developers contribute their advanced skills and domain
                > > knowledge across multiple projects, other developers cross-train for
                > > interchangeability, small companies can't afford dedicated teams on
                > > each project, etc.).
                > >
                > > If Joe Developer works on 3 projects, he has to track/attend 3 of
                > > everything (sprints, stand-ups, planning, review, retrospective). He
                > > has to keep track of all his work across all 3 projects. Depending
                > > on the situation, he might work on projects in priority order (one
                > > project at a time), or he might work on his tasks in priority order
                > > (jumping from one project to another).
                > >
                > > [Q:] What is your experience with this? I'm sure it's preferred to
                > > have developers/teams dedicated to a single project, but I'm curious
                > > how common this scenario has been in your experience and how you've
                > > handled it. Should the sprints be aligned or staggered?
                > >
                > > [Q:] What agile tools would you recommend overall for this scenario?
                > > I prefer tools that are free/cheap, simple/intuitive, fast/
                > > responsive, with potential integration with third-party defect
                > > tracking, wiki pages, etc.
                > >
                > > I've researched some nice agile tools that provide easy user story
                > > specification with drag-n-drop prioritization, easy drag-n-drop
                > > sprint planning, task breakdown, storyboard drag-n-drop, reporting,
                > > etc. BUT... tools that manage multiple projects, and enable
                > > developers to see their tasks across multiple projects, seem to cost
                > > more and have increased complexity.
                > >
                > > In summary, I want to learn the best way to manage this situation
                > > (developers on multiple projects), and I want to find cost-
                > > effective, simple tools to help the team be most productive when
                > > dedicated teams are not an option.
                >
              • George Dinwiddie
                ... That s the job of that single PO, to work on things in a fashion that makes sense. The PO can track the individual projects separately. ... It s always
                Message 7 of 13 , Jan 2, 2010
                • 0 Attachment
                  bmwpapa wrote:
                  > Thanks Elizabeth. If I read you correctly, you seem to describe a
                  > single backlog, managed by a single PO, with ONE team, across
                  > multiple projects.
                  >
                  > This appears to be more story/task-centric, rather than
                  > project/release-centric - i.e. work on stories/tasks in order of
                  > priority, regardless of which project/release it's for. But, then,
                  > how do you track your release burndown, velocity, and goals/progress
                  > for individual projects? Each project should be release-able after
                  > each sprint, but each sprint tracks multiple projects. Unless I'm
                  > missing something, this approach seems to cloud the bigger picture.

                  That's the job of that single PO, to work on things in a fashion that
                  makes sense. The PO can track the individual projects separately.

                  > In response to other posts...
                  >
                  > Andre seems to suggest that developers on multiple projects is plain
                  > wrong. I understand it's not preferred, but I'm not convinced it's
                  > always avoidable.

                  It's always avoidable if you want to avoid it. That people often let
                  activity get in the way of progress is no reason to accept it as a
                  necessary part of your life. Maybe you want to read "Getting Things
                  Done." What Andre suggests is the same principle, applied to a software
                  development team. Do things in chunks that are useful and distinct.

                  > I'm still interested to hear more real-world experiences...

                  I highly recommend that you read Johanna's book on portfolio management.

                  - George

                  --
                  ----------------------------------------------------------------------
                  * George Dinwiddie * http://blog.gdinwiddie.com
                  Software Development http://www.idiacomputing.com
                  Consultant and Coach http://www.agilemaryland.org
                  ----------------------------------------------------------------------
                • Maurice le Rutte
                  bmwpapa schreef: Maurice seems to think that I want everything , but I m willing to pay nothing . However, I m really just stating the obvious preference
                  Message 8 of 13 , Jan 2, 2010
                  • 0 Attachment
                    bmwpapa schreef:
                     

                    Maurice seems to think that I want "everything" , but I'm willing to pay "nothing". However, I'm really just stating the obvious preference for cost-effectiveness. I want the biggest bang for the buck. Who doesn't?

                    __

                    It was more of an observation that very often people query about a tool and then state that they are not very willing to pay for it, not a comment specifically too you. Of course everybody wants cost-effectiveness, but that is with everything you buy. What is cost effective depends on your situation and can't be judged by me, so asking for something cost-effective to others might not give you the answer that matches your preferences the best.

                    If a person would ask you where he can get something to eat and then states that the meal may not cost to much but it should preferably a lot than you are more likely to refer the person to a fast-food restaurant rather than to a haute cuisine. Obviously the experience is completely different. So it might be better to first find out what the person would expect, after which you can always decide that haute cuisine is not what you want.

                    On the other hand, developers are expensive. Loosing market is expensive. Developer stations also cost quite some money, as do desks, heating etc etc. That is all accepted, but we don't want to spend money on a tool that could save money.

                    Maurice.
                    -- 
                    http://www.scrummaster.nl / http://twitter.com/scrumnl
                  • Elizabeth V Woodward
                    Hi bmwpapa, ... Correct. We re looking at a situation where team members of ONE team might be working on a couple of different projects at a given time. Bob,
                    Message 9 of 13 , Jan 3, 2010
                    • 0 Attachment
                      Hi bmwpapa,

                      > Thanks Elizabeth. If I read you correctly, you seem to describe a
                      > single backlog, managed by a single PO, with ONE team, across
                      > multiple projects.


                      Correct. We're looking at a situation where team members of ONE team might be working on a couple of different projects at a given time. Bob, Mary and Cindy may need to work on Project A during one Sprint and Tim, Meg, and Dan might work on Project B during that same Sprint. Next Sprint, Bob, Mary and Dan may need to work on Project A, etc. In the end, all members of the team are responsible for both projects.
                       
                      > This appears to be more story/task-centric, rather than project/
                      > release-centric - i.e. work on stories/tasks in order of priority,
                      > regardless of which project/release it's for.


                      It is project/release-centric, though. Consider one point in time, there were two clients and the team was working on two projects, one for each of the two clients. If the team worked from two different backlogs, we would end up with competing priorities. Is Story A in product backlog A more important than Story A in product backlog B? Who decides? Toss in a request from the CEO for help with a proposal in the upcoming Sprint and it's easy for the team to be split in a lot of different directions without a clear understanding of what's most valuable/important. One backlog means the business is making a clear decision about what the priorities are and everyone can see the trade-offs. It's easier to see what happens to stories/progress for Project A or Project B when the CEO asks the team to take on a 40pt proposal for the next Sprint and their velocity is showing an average of 80 pts per Sprint. With multiple backlogs, it's not so obvious.  (I've also witnessed separate backlogs for one team with a 40% velocity on Project A and 60% velocity on Project B sort of thing...I'm much, MUCH less excited about that actually...)

                      > But, then, how do you
                      > track your release burndown, velocity, and goals/progress for
                      > individual projects? Each project should be release-able after each
                      > sprint, but each sprint tracks multiple projects. Unless I'm missing
                      > something, this approach seems to cloud the bigger picture.


                      Yes, you're still looking at breaking down the work for each project into chunks that can be completed--done done done--at the end of each Sprint and is looking to deliver a releaseable product (for each project) at the end of each Sprint. No change there. Velocity is tracked for the whole team, everyone has a common understanding of relative sizes and what a "point" means. You're still tracking the amount of work remaining for each project in your release burndown charts, no change there. But, yes, you're associating the story with the project (in your spreadsheet, card or whatever tool) so that you can track. No clouding for us... crystal clear clarification, awareness of big-picturing impact across projects, understanding of where we are and where we're going.

                      >
                      > In response to other posts...
                      >
                      > Andre seems to suggest that developers on multiple projects is plain
                      > wrong. I understand it's not preferred, but I'm not convinced it's
                      > always avoidable.


                      I'm sure folks will cringe, but for the company I'm describing...working on multiple projects worked out very nicely for the company and for the team. Using Scrum in this way, clients were happy, the team aligned deliverables with the customers' expectations, quality was good and the team delivered value at the end of each Sprint, we reached a comfortable sustainable pace, etc.

                      -elizabeth
                       
                      > Maurice seems to think that I want "everything", but I'm
                      willing to
                      > pay "nothing". However, I'm really just stating the obvious
                      > preference for cost-effectiveness. I want the biggest bang for the
                      > buck. Who doesn't?
                      >
                      > I'm still interested to hear more real-world experiences...
                      >
                      > --- In scrumdevelopment@yahoogroups.com, Elizabeth V Woodward
                      > <evwoodwa@...> wrote:
                      > >
                      > > I was brought in to help a smaller company a while back… What
                      I found was
                      > > that the teams were made up of some really amazingly talented
                      people… The
                      > > biggest problem was that they were constantly being interrupted
                      when
                      > > working on one thing to work on something else. Along with the
                      multiple
                      > > projects, there were multiple contacts who could shift the team’s
                      > > attention…project managers for each project on the client
                      side, project
                      > > managers for each project on the company’s side, the CEO
                      of the company,
                      > > the CIO, etc. Not good.
                      > >
                      > > Because it was a small company, having the entire team dedicated
                      to one
                      > > project would not have worked. There were lulls in activities
                      where the
                      > > client was reviewing information with subject matter experts
                      or gathering
                      > > data for the project. During that time, the team had cycles to
                      work on
                      > > other projects. Additionally, there really were time-sensitive,
                      critical
                      > > work items (developing a time-sensitive proposal with some initial
                      > > modeling for a potential client, for example) that needed to
                      be done in
                      > > parallel with current project work. It wouldn’t make sense
                      to wait until
                      > > the end of one project to work on the proposal, for example.
                      > >
                      > > What we did was set up a backlog of all of the work for the whole
                      team,
                      > > owned and prioritized by one person. The CEO determined who would
                      serve as
                      > > that Product Owner. That Product Owner took input from the different
                      > > project contacts, the Team, etc, andâ€"based on knowledge
                      of the projects,
                      > > technical constraints, business impact, the team’s capabilities/input
                      and
                      > > info they provided on the cost of context switchingâ€"the
                      PO was ultimately
                      > > responsible for the order/prioritization of work items in the
                      backlog.
                      > > This helped to eliminate the thrashing we were seeing. It also
                      made
                      > > visible problems with too many projects in play at a given time.
                      Using
                      > > velocity and looking at the size of the work items, everyone
                      had a much
                      > > more realistic picture of what user stories and other work items
                      could be
                      > > accomplished. Engaging clients for the reviews and planning ensured
                      that
                      > > we stayed in alignment with clients' expectations.
                      > > The whole team (7 people) participated in ONE Daily Scrum, so
                      everyone
                      > > knew what everyone else was working on. The team answered the
                      three
                      > > questions, focused on discussing dependencies they had on each
                      other, let
                      > > other people know when they needed help, discussed potential
                      blockers,
                      > > etc. We were able to much more quickly identify and address issues.
                      We did
                      > > not have separate Daily Scrums depending on which people were
                      working on
                      > > which projects during that Sprint. Everyone was on the same Sprint
                      cycle.
                      > > We did not have a separate planning meeting for each project
                      with user
                      > > stories that would be addressed that Sprint or separate retrospectives
                      for
                      > > each project. The Team planned and reflected together. However,
                      we did
                      > > have separate demos/reviews with the appropriate stakeholders
                      for the
                      > > different projects.
                      > > -elizabeth
                      > >
                      > > > Please respond to scrumdevelopment
                      > > >
                      > > >
                      > > > Here's an example scenario, based on real-world situations,
                      for your
                      > > > feedback...
                      > > >
                      > > > Company A is a small company with 5 projects, and 10 developers.
                      > > >
                      > > > Developers work on multiple projects. This is for various
                      reasons
                      > > > (senior developers contribute their advanced skills and
                      domain
                      > > > knowledge across multiple projects, other developers cross-train
                      for
                      > > > interchangeability, small companies can't afford dedicated
                      teams on
                      > > > each project, etc.).
                      > > >
                      > > > If Joe Developer works on 3 projects, he has to track/attend
                      3 of
                      > > > everything (sprints, stand-ups, planning, review, retrospective).
                      He
                      > > > has to keep track of all his work across all 3 projects.
                      Depending
                      > > > on the situation, he might work on projects in priority
                      order (one
                      > > > project at a time), or he might work on his tasks in priority
                      order
                      > > > (jumping from one project to another).
                      > > >
                      > > > [Q:] What is your experience with this? I'm sure it's preferred
                      to
                      > > > have developers/teams dedicated to a single project, but
                      I'm curious
                      > > > how common this scenario has been in your experience and
                      how you've
                      > > > handled it. Should the sprints be aligned or staggered?
                      > > >
                      > > > [Q:] What agile tools would you recommend overall for this
                      scenario?
                      > > > I prefer tools that are free/cheap, simple/intuitive, fast/
                      > > > responsive, with potential integration with third-party
                      defect
                      > > > tracking, wiki pages, etc.
                      > > >
                      > > > I've researched some nice agile tools that provide easy
                      user story
                      > > > specification with drag-n-drop prioritization, easy drag-n-drop
                      > > > sprint planning, task breakdown, storyboard drag-n-drop,
                      reporting,
                      > > > etc. BUT... tools that manage multiple projects, and enable
                      > > > developers to see their tasks across multiple projects,
                      seem to cost
                      > > > more and have increased complexity.
                      > > >
                      > > > In summary, I want to learn the best way to manage this
                      situation
                      > > > (developers on multiple projects), and I want to find cost-
                      > > > effective, simple tools to help the team be most productive
                      when
                      > > > dedicated teams are not an option.
                      > >

                      >
                    • Roy Morien
                      What is a 40% velocity amd a 60% velocity ? I thought that velocity was an absolute measure of team output, however measured. If there is such a concept as
                      Message 10 of 13 , Jan 3, 2010
                      • 0 Attachment
                        What is a '40% velocity' amd a '60% velocity'? I thought that velocity was an absolute measure of team output, however measured.
                         
                        If there is such a concept as '60% velocity', where, who and how is the 100% decided, and how is it measured and published?
                         
                        Regards,
                        Roy Morien 
                         

                        To: scrumdevelopment@yahoogroups.com
                        From: evwoodwa@...
                        Date: Sun, 3 Jan 2010 15:24:16 -0600
                        Subject: Re: [scrumdevelopment] Re: Developers on multiple projects

                         

                        Hi bmwpapa,

                        > Thanks Elizabeth. If I read you correctly, you seem to describe a
                        > single backlog, managed by a single PO, with ONE team, across
                        > multiple projects.


                        Correct. We're looking at a situation where team members of ONE team might be working on a couple of different projects at a given time. Bob, Mary and Cindy may need to work on Project A during one Sprint and Tim, Meg, and Dan might work on Project B during that same Sprint. Next Sprint, Bob, Mary and Dan may need to work on Project A, etc. In the end, all members of the team are responsible for both projects.
                         
                        > This appears to be more story/task-centric, rather than project/
                        > release-centric - i.e. work on stories/tasks in order of priority,
                        > regardless of which project/release it's for.


                        It is project/release- centric, though. Consider one point in time, there were two clients and the team was working on two projects, one for each of the two clients. If the team worked from two different backlogs, we would end up with competing priorities. Is Story A in product backlog A more important than Story A in product backlog B? Who decides? Toss in a request from the CEO for help with a proposal in the upcoming Sprint and it's easy for the team to be split in a lot of different directions without a clear understanding of what's most valuable/important. One backlog means the business is making a clear decision about what the priorities are and everyone can see the trade-offs. It's easier to see what happens to stories/progress for Project A or Project B when the CEO asks the team to take on a 40pt proposal for the next Sprint and their velocity is showing an average of 80 pts per Sprint. With multiple backlogs, it's not so obvious.  (I've also witnessed separate backlogs for one team with a 40% velocity on Project A and 60% velocity on Project B sort of thing...I'm much, MUCH less excited about that actually...)

                        > But, then, how do you
                        > track your release burndown, velocity, and goals/progress for
                        > individual projects? Each project should be release-able after each
                        > sprint, but each sprint tracks multiple projects. Unless I'm missing
                        > something, this approach seems to cloud the bigger picture.


                        Yes, you're still looking at breaking down the work for each project into chunks that can be completed--done done done--at the end of each Sprint and is looking to deliver a releaseable product (for each project) at the end of each Sprint. No change there. Velocity is tracked for the whole team, everyone has a common understanding of relative sizes and what a "point" means. You're still tracking the amount of work remaining for each project in your release burndown charts, no change there. But, yes, you're associating the story with the project (in your spreadsheet, card or whatever tool) so that you can track. No clouding for us... crystal clear clarification, awareness of big-picturing impact across projects, understanding of where we are and where we're going.

                        >
                        > In response to other posts...
                        >
                        > Andre seems to suggest that developers on multiple projects is plain
                        > wrong. I understand it's not preferred, but I'm not convinced it's
                        > always avoidable.


                        I'm sure folks will cringe, but for the company I'm describing.. .working on multiple projects worked out very nicely for the company and for the team. Using Scrum in this way, clients were happy, the team aligned deliverables with the customers' expectations, quality was good and the team delivered value at the end of each Sprint, we reached a comfortable sustainable pace, etc.

                        -elizabeth
                         
                        > Maurice seems to think that I want "everything", but I'm willing to
                        > pay "nothing". However, I'm really just stating the obvious
                        > preference for cost-effectiveness. I want the biggest bang for the
                        > buck. Who doesn't?
                        >
                        > I'm still interested to hear more real-world experiences. ..
                        >
                        > --- In scrumdevelopment@ yahoogroups. com, Elizabeth V Woodward
                        > <evwoodwa@...> wrote:
                        > >
                        > > I was brought in to help a smaller company a while back… What I found was
                        > > that the teams were made up of some really amazingly talented people… The
                        > > biggest problem was that they were constantly being interrupted when
                        > > working on one thing to work on something else. Along with the multiple
                        > > projects, there were multiple contacts who could shift the team’s
                        > > attention…project managers for each project on the client side, project
                        > > managers for each project on the company’s side, the CEO of the company,
                        > > the CIO, etc. Not good.
                        > >
                        > > Because it was a small company, having the entire team dedicated to one
                        > > project would not have worked. There were lulls in activities where the
                        > > client was reviewing information with subject matter experts or gathering
                        > > data for the project. During that time, the team had cycles to work on
                        > > other projects. Additionally, there really were time-sensitive, critical
                        > > work items (developing a time-sensitive proposal with some initial
                        > > modeling for a potential client, for example) that needed to be done in
                        > > parallel with current project work. It wouldn’t make sense to wait until
                        > > the end of one project to work on the proposal, for example.
                        > >
                        > > What we did was set up a backlog of all of the work for the whole team,
                        > > owned and prioritized by one person. The CEO determined who would serve as
                        > > that Product Owner. That Product Owner took input from the different
                        > > project contacts, the Team, etc, andâ€"based on knowledge of the projects,
                        > > technical constraints, business impact, the team’s capabilities/ input and
                        > > info they provided on the cost of context switchingâ€"the PO was ultimately
                        > > responsible for the order/prioritizatio n of work items in the backlog.
                        > > This helped to eliminate the thrashing we were seeing. It also made
                        > > visible problems with too many projects in play at a given time. Using
                        > > velocity and looking at the size of the work items, everyone had a much
                        > > more realistic picture of what user stories and other work items could be
                        > > accomplished. Engaging clients for the reviews and planning ensured that
                        > > we stayed in alignment with clients' expectations.
                        > > The whole team (7 people) participated in ONE Daily Scrum, so everyone
                        > > knew what everyone else was working on. The team answered the three
                        > > questions, focused on discussing dependencies they had on each other, let
                        > > other people know when they needed help, discussed potential blockers,
                        > > etc. We were able to much more quickly identify and address issues. We did
                        > > not have separate Daily Scrums depending on which people were working on
                        > > which projects during that Sprint. Everyone was on the same Sprint cycle.
                        > > We did not have a separate planning meeting for each project with user
                        > > stories that would be addressed that Sprint or separate retrospectives for
                        > > each project. The Team planned and reflected together. However, we did
                        > > have separate demos/reviews with the appropriate stakeholders for the
                        > > different projects.
                        > > -elizabeth
                        > >
                        > > > Please respond to scrumdevelopment
                        > > >
                        > > >
                        > > > Here's an example scenario, based on real-world situations, for your
                        > > > feedback...
                        > > >
                        > > > Company A is a small company with 5 projects, and 10 developers.
                        > > >
                        > > > Developers work on multiple projects. This is for various reasons
                        > > > (senior developers contribute their advanced skills and domain
                        > > > knowledge across multiple projects, other developers cross-train for
                        > > > interchangeability, small companies can't afford dedicated teams on
                        > > > each project, etc.).
                        > > >
                        > > > If Joe Developer works on 3 projects, he has to track/attend 3 of
                        > > > everything (sprints, stand-ups, planning, review, retrospective) . He
                        > > > has to keep track of all his work across all 3 projects. Depending
                        > > > on the situation, he might work on projects in priority order (one
                        > > > project at a time), or he might work on his tasks in priority order
                        > > > (jumping from one project to another).
                        > > >
                        > > > [Q:] What is your experience with this? I'm sure it's preferred to
                        > > > have developers/teams dedicated to a single project, but I'm curious
                        > > > how common this scenario has been in your experience and how you've
                        > > > handled it. Should the sprints be aligned or staggered?
                        > > >
                        > > > [Q:] What agile tools would you recommend overall for this scenario?
                        > > > I prefer tools that are free/cheap, simple/intuitive, fast/
                        > > > responsive, with potential integration with third-party defect
                        > > > tracking, wiki pages, etc.
                        > > >
                        > > > I've researched some nice agile tools that provide easy user story
                        > > > specification with drag-n-drop prioritization, easy drag-n-drop
                        > > > sprint planning, task breakdown, storyboard drag-n-drop, reporting,
                        > > > etc. BUT... tools that manage multiple projects, and enable
                        > > > developers to see their tasks across multiple projects, seem to cost
                        > > > more and have increased complexity.
                        > > >
                        > > > In summary, I want to learn the best way to manage this situation
                        > > > (developers on multiple projects), and I want to find cost-
                        > > > effective, simple tools to help the team be most productive when
                        > > > dedicated teams are not an option.
                        > >

                        >


                        Australia's #1 job site If It Exists, You'll Find it on SEEK
                      • bmwpapa
                        Thanks Elizabeth and Johanna. I really appreciate your time and thoughtful responses. Summary: - Developers should ideally be dedicated to ONE project at a
                        Message 11 of 13 , Jan 3, 2010
                        • 0 Attachment
                          Thanks Elizabeth and Johanna. I really appreciate your time and thoughtful responses.

                          Summary:
                          - Developers should ideally be dedicated to ONE project at a time.
                          - Manage your project portfolio (commit/kill/transform).
                          - If developers must span multiple projects, consider ONE team/backlog/PO "uber" project.

                          I'm still not clear about release burndown tracking of individual projects, though. Elizabeth, when you wrote "release burndown charts" below, did you really mean "sprint burndown charts"?

                          Elizabeth wrote:
                          > You're still tracking the amount of work remaining for
                          > each project in your release burndown charts, no change there.

                          My question was regarding RELEASE burndowns, not SPRINT burndowns. In this scenario, you're suggesting ONE backlog with stories across ALL projects, so this agile "uber" project is tracking multiple project releases as a single release, right? How does one track a release burndown of stories that pertain to INDIVIDUAL projects?

                          I hope my question makes sense.


                          --- In scrumdevelopment@yahoogroups.com, Elizabeth V Woodward <evwoodwa@...> wrote:
                          >
                          > Hi bmwpapa,
                          >
                          > > Thanks Elizabeth. If I read you correctly, you seem to describe a
                          > > single backlog, managed by a single PO, with ONE team, across
                          > > multiple projects.
                          >
                          > Correct. We're looking at a situation where team members of ONE team might
                          > be working on a couple of different projects at a given time. Bob, Mary
                          > and Cindy may need to work on Project A during one Sprint and Tim, Meg,
                          > and Dan might work on Project B during that same Sprint. Next Sprint, Bob,
                          > Mary and Dan may need to work on Project A, etc. In the end, all members
                          > of the team are responsible for both projects.
                          >
                          > > This appears to be more story/task-centric, rather than project/
                          > > release-centric - i.e. work on stories/tasks in order of priority,
                          > > regardless of which project/release it's for.
                          >
                          > It is project/release-centric, though. Consider one point in time, there
                          > were two clients and the team was working on two projects, one for each of
                          > the two clients. If the team worked from two different backlogs, we would
                          > end up with competing priorities. Is Story A in product backlog A more
                          > important than Story A in product backlog B? Who decides? Toss in a
                          > request from the CEO for help with a proposal in the upcoming Sprint and
                          > it's easy for the team to be split in a lot of different directions
                          > without a clear understanding of what's most valuable/important. One
                          > backlog means the business is making a clear decision about what the
                          > priorities are and everyone can see the trade-offs. It's easier to see
                          > what happens to stories/progress for Project A or Project B when the CEO
                          > asks the team to take on a 40pt proposal for the next Sprint and their
                          > velocity is showing an average of 80 pts per Sprint. With multiple
                          > backlogs, it's not so obvious. (I've also witnessed separate backlogs for
                          > one team with a 40% velocity on Project A and 60% velocity on Project B
                          > sort of thing...I'm much, MUCH less excited about that actually...)
                          >
                          > > But, then, how do you
                          > > track your release burndown, velocity, and goals/progress for
                          > > individual projects? Each project should be release-able after each
                          > > sprint, but each sprint tracks multiple projects. Unless I'm missing
                          > > something, this approach seems to cloud the bigger picture.
                          >
                          > Yes, you're still looking at breaking down the work for each project into
                          > chunks that can be completed--done done done--at the end of each Sprint
                          > and is looking to deliver a releaseable product (for each project) at the
                          > end of each Sprint. No change there. Velocity is tracked for the whole
                          > team, everyone has a common understanding of relative sizes and what a
                          > "point" means. You're still tracking the amount of work remaining for each
                          > project in your release burndown charts, no change there. But, yes, you're
                          > associating the story with the project (in your spreadsheet, card or
                          > whatever tool) so that you can track. No clouding for us... crystal clear
                          > clarification, awareness of big-picturing impact across projects,
                          > understanding of where we are and where we're going.
                          >
                          > >
                          > > In response to other posts...
                          > >
                          > > Andre seems to suggest that developers on multiple projects is plain
                          > > wrong. I understand it's not preferred, but I'm not convinced it's
                          > > always avoidable.
                          >
                          > I'm sure folks will cringe, but for the company I'm describing...working
                          > on multiple projects worked out very nicely for the company and for the
                          > team. Using Scrum in this way, clients were happy, the team aligned
                          > deliverables with the customers' expectations, quality was good and the
                          > team delivered value at the end of each Sprint, we reached a comfortable
                          > sustainable pace, etc.
                          >
                          > -elizabeth
                          >
                          > > Maurice seems to think that I want "everything", but I'm willing to
                          > > pay "nothing". However, I'm really just stating the obvious
                          > > preference for cost-effectiveness. I want the biggest bang for the
                          > > buck. Who doesn't?
                          > >
                          > > I'm still interested to hear more real-world experiences...
                          > >
                          > > --- In scrumdevelopment@yahoogroups.com, Elizabeth V Woodward
                          > > <evwoodwa@> wrote:
                          > > >
                          > > > I was brought in to help a smaller company a while back… What I
                          > found was
                          > > > that the teams were made up of some really amazingly talented
                          > people… The
                          > > > biggest problem was that they were constantly being interrupted when
                          > > > working on one thing to work on something else. Along with the
                          > multiple
                          > > > projects, there were multiple contacts who could shift the team’s
                          > > > attention…project managers for each project on the client side,
                          > project
                          > > > managers for each project on the company’s side, the CEO of the
                          > company,
                          > > > the CIO, etc. Not good.
                          > > >
                          > > > Because it was a small company, having the entire team dedicated to
                          > one
                          > > > project would not have worked. There were lulls in activities where
                          > the
                          > > > client was reviewing information with subject matter experts or
                          > gathering
                          > > > data for the project. During that time, the team had cycles to work on
                          >
                          > > > other projects. Additionally, there really were time-sensitive,
                          > critical
                          > > > work items (developing a time-sensitive proposal with some initial
                          > > > modeling for a potential client, for example) that needed to be done
                          > in
                          > > > parallel with current project work. It wouldn’t make sense to wait
                          > until
                          > > > the end of one project to work on the proposal, for example.
                          > > >
                          > > > What we did was set up a backlog of all of the work for the whole
                          > team,
                          > > > owned and prioritized by one person. The CEO determined who would
                          > serve as
                          > > > that Product Owner. That Product Owner took input from the different
                          > > > project contacts, the Team, etc, andâ€"based on knowledge of the
                          > projects,
                          > > > technical constraints, business impact, the team’s
                          > capabilities/input and
                          > > > info they provided on the cost of context switchingâ€"the PO was
                          > ultimately
                          > > > responsible for the order/prioritization of work items in the backlog.
                          >
                          > > > This helped to eliminate the thrashing we were seeing. It also made
                          > > > visible problems with too many projects in play at a given time. Using
                          >
                          > > > velocity and looking at the size of the work items, everyone had a
                          > much
                          > > > more realistic picture of what user stories and other work items could
                          > be
                          > > > accomplished. Engaging clients for the reviews and planning ensured
                          > that
                          > > > we stayed in alignment with clients' expectations.
                          > > > The whole team (7 people) participated in ONE Daily Scrum, so everyone
                          >
                          > > > knew what everyone else was working on. The team answered the three
                          > > > questions, focused on discussing dependencies they had on each other,
                          > let
                          > > > other people know when they needed help, discussed potential blockers,
                          >
                          > > > etc. We were able to much more quickly identify and address issues. We
                          > did
                          > > > not have separate Daily Scrums depending on which people were working
                          > on
                          > > > which projects during that Sprint. Everyone was on the same Sprint
                          > cycle.
                          > > > We did not have a separate planning meeting for each project with user
                          >
                          > > > stories that would be addressed that Sprint or separate retrospectives
                          > for
                          > > > each project. The Team planned and reflected together. However, we did
                          >
                          > > > have separate demos/reviews with the appropriate stakeholders for the
                          > > > different projects.
                          > > > -elizabeth
                          > > >
                          > > > > Please respond to scrumdevelopment
                          > > > >
                          > > > >
                          > > > > Here's an example scenario, based on real-world situations, for your
                          > > > > feedback...
                          > > > >
                          > > > > Company A is a small company with 5 projects, and 10 developers.
                          > > > >
                          > > > > Developers work on multiple projects. This is for various reasons
                          > > > > (senior developers contribute their advanced skills and domain
                          > > > > knowledge across multiple projects, other developers cross-train for
                          > > > > interchangeability, small companies can't afford dedicated teams on
                          > > > > each project, etc.).
                          > > > >
                          > > > > If Joe Developer works on 3 projects, he has to track/attend 3 of
                          > > > > everything (sprints, stand-ups, planning, review, retrospective). He
                          > > > > has to keep track of all his work across all 3 projects. Depending
                          > > > > on the situation, he might work on projects in priority order (one
                          > > > > project at a time), or he might work on his tasks in priority order
                          > > > > (jumping from one project to another).
                          > > > >
                          > > > > [Q:] What is your experience with this? I'm sure it's preferred to
                          > > > > have developers/teams dedicated to a single project, but I'm curious
                          > > > > how common this scenario has been in your experience and how you've
                          > > > > handled it. Should the sprints be aligned or staggered?
                          > > > >
                          > > > > [Q:] What agile tools would you recommend overall for this scenario?
                          > > > > I prefer tools that are free/cheap, simple/intuitive, fast/
                          > > > > responsive, with potential integration with third-party defect
                          > > > > tracking, wiki pages, etc.
                          > > > >
                          > > > > I've researched some nice agile tools that provide easy user story
                          > > > > specification with drag-n-drop prioritization, easy drag-n-drop
                          > > > > sprint planning, task breakdown, storyboard drag-n-drop, reporting,
                          > > > > etc. BUT... tools that manage multiple projects, and enable
                          > > > > developers to see their tasks across multiple projects, seem to cost
                          > > > > more and have increased complexity.
                          > > > >
                          > > > > In summary, I want to learn the best way to manage this situation
                          > > > > (developers on multiple projects), and I want to find cost-
                          > > > > effective, simple tools to help the team be most productive when
                          > > > > dedicated teams are not an option.
                          > > >
                          >
                          > >
                          >
                        • Ron Jeffries
                          ... I took the OP to mean 40 percent of the team s full capacity goes to project A ; Ron Jeffries www.XProgramming.com www.xprogramming.com/blog Learning is a
                          Message 12 of 13 , Jan 4, 2010
                          • 0 Attachment
                            Hello, Roy. On Sunday, January 3, 2010, at 10:52:24 PM, you wrote:

                            > What is a '40% velocity' amd a '60% velocity'? I thought that
                            > velocity was an absolute measure of team output, however measured.

                            I took the OP to mean "40 percent of the team's full capacity goes
                            to project A";

                            Ron Jeffries
                            www.XProgramming.com
                            www.xprogramming.com/blog
                            Learning is a human process, and knowledge is not what is found in the library.
                          • George Dinwiddie
                            ... The team can have a sprint burndown for the work they commit to finish during the sprint. Each project can have a release burndown (or burnup, which is my
                            Message 13 of 13 , Jan 4, 2010
                            • 0 Attachment
                              bmwpapa wrote:
                              > I'm still not clear about release burndown tracking of individual
                              > projects, though. Elizabeth, when you wrote "release burndown
                              > charts" below, did you really mean "sprint burndown charts"?
                              >
                              > Elizabeth wrote:
                              >> You're still tracking the amount of work remaining for each project
                              >> in your release burndown charts, no change there.
                              >
                              > My question was regarding RELEASE burndowns, not SPRINT burndowns.
                              > In this scenario, you're suggesting ONE backlog with stories across
                              > ALL projects, so this agile "uber" project is tracking multiple
                              > project releases as a single release, right? How does one track a
                              > release burndown of stories that pertain to INDIVIDUAL projects?

                              The team can have a sprint burndown for the work they commit to finish
                              during the sprint. Each project can have a release burndown (or burnup,
                              which is my preference) for work required for the release.

                              I prefer using a burnup for this, as the scope of a release can be
                              flexible. See
                              http://idiacomputing.com/pub/BetterSoftware-BurnCharts.pdf for more on this.

                              - George


                              --
                              ----------------------------------------------------------------------
                              * George Dinwiddie * http://blog.gdinwiddie.com
                              Software Development http://www.idiacomputing.com
                              Consultant and Coach http://www.agilemaryland.org
                              ----------------------------------------------------------------------
                            Your message has been successfully submitted and would be delivered to recipients shortly.