My question is similar to these two topics;

but where my team fails is when we are all working on separate projects and we get bombarded with input from many other departments.

I'm sure Scrum and Agile are similar in that, once the project is started after its defined, there should be very little if not no input or changes to the plan. This tends to fail every time no matter the size of the project. We do have the support of the company and product owner but some of these problems originate from that very same person.

How can we minimize these outside interruptions to the project?

  • 2
    I'm not sure this fits the Stack Q&A model, because you are asking for suggestions - similar to a forum - not a canonical answer to a specific question. But, (a) I don't want to leave you hanging, and (b) I don't see a way to message you directly. – Josh Bruce Nov 7 '13 at 0:43
  • 1
    Hey @JoshBruce, if you know what an asker is getting at and can see beyond the "any suggestions" veil, feel free to make a suggested edit on the post to help improve it. Anything we can do to help new users' posts meet our quality standards helps create a lasting resource of knowledge for future readers for years to come. Hope this helps! :) – jmort253 Nov 7 '13 at 3:30
  • Thank you both for your comments. I will do better in the future to direct my posts as more of a question. – epool Nov 7 '13 at 5:02
  • @epool I encourage you to edit as well. We're building an encyclopedia of knowledge in the field of project management, and folks asking the questions are just as important to our success as the ones answering. :) One of the most powerful features of our site is the editing; we can always improve! Hope this helps, and welcome to our community! :) – jmort253 Nov 7 '13 at 6:14
  • @jmort253 - I'm still a little freaked out about editing someone's writing, but I get what you're saying and will try to be less of a, "Hey, this is Q&A" person, when applicable. :) – Josh Bruce Nov 8 '13 at 2:06

The following is pulled from a few different sources (including my own experience as a solo freelancer with multiple clients); however, you mentioned Agile and Scrum - so my terminology will be similar.

  1. Shorter development efforts, with extended silence:

    What I found worked for me was to have, essentially, a one week sprint. On Monday, you meet the product owners - or collect the input from all of them and set priorities for the week. Developers forecast what they think they can do by Friday. Then, get to work.

    Friday comes, you show what you did. The three of you chat about what worked in the processes you actually control - and make improvements. Weekend. Monday - rinse and repeat.

    If the product owner(s) can't calm down for 4 days and let you do your work uninterrupted, then there's probably a bigger problem.

  2. Definition of done:

    You all (product owners included) should define what "done" means for each task that will be in the sprint. It may start out as "it just works" - but there should be a drive/desire amongst the team to refine and mature the definition to include engineering excellence.

  3. Definition of ready:

    Don't accept into a sprint items which have not been crystalized to a certain, agreed upon, state. This may start out as simple and very generic descriptions (button in top left) - but there should be a drive/desire to improve to having mock-ups, maybe multiple requirements written in an FDD or BDD style in the language of the business...and so on.

  4. The only way to change direction is to stop first:

    So, you've got:

    • Entrance criteria (ex. If an item isn't broken down enough to be done in 1 week - we don't do it);
    • Exit criteria (ex. It just works); and
    • A communication plan (we meet Mondays and Fridays - and possibly daily for 15 minutes, but that should be more for the team doing the work - not the product owner) - between that time the PO can't say anything...

    If, for whatever reason, the product owner(s) has (have) to change things mid-sprint, it's okay and, in scrum at least, there's a simple way to do it - tell the developers to stop what they're doing, possibly abandon all the work to date, and start again.

    If this happens, I highly recommend modifying sprint lengths to get back on the Monday-Friday timetable (it works wonders if you're on that sort of weekday schedule - modify for whenever the team gets time off).

  5. Two levels of defects - developers only hear about one during a sprint:

    Level 1 defects mean stuff is crashing, horribly, it's bad, really bad. Level 2 is everything else - we found a glitch and a workaround, or we want this to be yellow.

    During a sprint (all 4 days of it, because the 5th cumulatively is taken up by meetings), the team is only informed of level 1 defects. Further, when the team is informed of a level 1 defect - all of the developers stop what they're doing and assist to fix the problem. (This is known as "stopping the line" in Lean Manufacturing.)

Now, you may not be able to (or want to) implement all of these. Further, you're corporate culture may not be one where a dramatic shift like this is a good idea. So, start slow.

Maybe the Monday-Friday book-end meetings that cover: What we are going to do; what we did do; and, for the developers, how can we do it better? Then start adding things to it...at the sprint review (Friday meeting with the Product Owner) is a great place to suggest having a definition of done and ready. Number 4 may not need to be brought up at all - but, if the PO interrupts, just inform them on the day; or, again, at the sprint review just bring it up and say, "You know, when you do that..."

Hope that helps.

  • 1
    I don't think i could have asked for a better answer. Thank you for taking the time to compile this. Reading it on paper does make sense and the shorter sprints should solve a lot of our problems. Our PO tends to involve himself more than you would expect but we do what we can do as a team to keep the company happy. – epool Nov 7 '13 at 5:08
  • +1 for the Definition of Ready. This is an idea that isn't used nearly as often as it should be. – Todd A. Jacobs Nov 7 '13 at 14:15
  • One is glad to be of service. Glad it was helpful - edited for better readability, I hope. Thanks again for the kind words and acceptance of the answer. Cheers. – Josh Bruce Nov 8 '13 at 2:00


[W]here my team fails is when we are all working on separate projects and we get bombarded with input from many other departments.

Scrum is designed to handle exactly the problem you describe. Specifically:

  1. Your team should be collaboratively working on a single project, not multiple projects. If you have multiple projects running simultaneously, you will need multiple teams.
  2. The roles of Product Owner and Scrum Master are designed to limit the negative impact of "bombardment" from outside the team. It is fundamentally the Product Owner's job to filter stakeholder requirements and manage them through the Product Backlog.

Change Control Enforced by Sprint Planning

Scrum is a framework that embraces change, but enforces change control by limiting most developer-facing changes to the Backlog Grooming and Sprint Planning phases of the project.

The sprint itself is a protected work zone that does not allow new work or changed requirements into the iteration. If a change is truly important enough to warrant an explicit termination of the current sprint and a return to Sprint Planning, then the Product Owner is empowered to do that.

The fundamental idea is that the project remains flexible, but that making changes within an iteration has a real cost that needs to be made explicit to the project and to its parent organization. It is the Scrum Master's job to educate the organization about this framework requirement, and to enforce the rules of Scrum within the team and with the Product Owner.

Stakeholders still get what they want, but it requires a shift in both stakeholder and Scrum Team behavior. See below for more specifics.

Adjusting Sprint Length

Keeping your sprint lengths short increase overhead and reduce the maximum size of the team's units of work. However, it offers the project more inspect-and-adapt cycles during the life of the project, so this is an area where each project must find its own optimum sprint length.


While I agree with the answers above theoretically, see my answer in this link for how I managed to implement this. I know it can be extremely challenging to apply what is effectively an ideal in a real world environment that is currently chaos. I found the key to be small steps and introducing an 'inspect and adapt' process.


  • I think you should extract a precis from your other post, and then link to the original from here. Answers should be self-contained; while this is not a link-only answer, it could be improved a lot by quoting some of the content directly. – Todd A. Jacobs Nov 9 '13 at 1:21

Your Answer

