What planning and prioritization techniques are effective for Scrum teams and Product Owners working within an IT organization that uses waterfall planning behaviors at the release level? Are there ways to optimize the Scrum team's experience or otherwise buffer the team from the ensuring challenges?

  • 1
    Could you please explicitly state whether the project works in Scrum or in Waterfall?
    – yegor256
    Apr 6, 2011 at 9:47
  • Updated to specify Scrum teams. Good clarification. Apr 7, 2011 at 4:20
  • 1
    Thus far, the consensus seems to be "Add an adapter layer in the form of the product owner and get on with things." Is that accurate? Apr 12, 2011 at 3:28

3 Answers 3


One of tricks I use in agile teams which are working with old-school highly-formalized teams is mapping. The team should map basically every client's responsibility to some team member. It usually goes to project manager as it is the person who is closest to a client.

Then it is about "building the bridges" - effort aimed at translating whatever client said or wanted to the language and process understandable by the development team. In other words it means translating agile inside to formalized process outside.

It doesn't mean there are specific prioritization techniques PM should use. Actually agile techniques don't really tell you how you should prioritize features - they deal more with reacting for planned features. However it's definitely worth the effort to ask the customer to prioritize the list of features so you all know what to cut when times goes harsh.

UPDATE (basing on comment): An example: we have a couple of teams working internally on the same project for the client who has pretty formalized approach to project management. One of teams (team A) prefers to work agile way and introduces Scrum as their method of choice, while another (team B) prefers to work with the old waterfall-like method. The release planning, we want it or not will follow waterfall-like method. I assume project scope can be split among those teams as they work to some point independently. Now we have a few channels of interactions:

  • Team B with the client. In this case it is simple. Both, client and team follow similar process so the team probably just adjusts to the specific schedule proposed by the client.

  • Team A with the client. That's where it starts to be different. Client doesn't really care about iterative development, but team works that way. The problem is the team expects feedback from the client on each release. And that's where PM should kick in with their "building the bridges" effort. It's PM who should emulate the client with such tasks, so PM should actually learn, check, verify, etc. what the client really wants and share the feedback with the team. However, generally the scope won't be changing much, as it is BDUF project and the client believes everything was in specs.

  • Team A with Team B. This is another tricky one, but since both teams are in the same organization a few approaches may be tried. One is the same as between the Team A and the client -- "building bridges" which means that someone, probably the leader of Team A is translating agile approach to formal one used by another team back and forth. Another idea is to let collaboration happen spontaneously, considering the fact everyone works in the same company. Finally, teams can choose they keep their methods but whenever they need something from others they do respect how others work, e.g. when Team B wants some changes in API built by Team A, they respect that Team A don't make changes in the middle of sprint so they will implemented in another one.

  • Your use of "client" leads me to think I should additionally ask the similar question of how to do effective Scrum release and sprint planning against a fixed price bid as an outsourced organization, but that's been asked and explored many times before in other forums. In this case, I'm specifically thinking for internal IT organizations, and will update the question to match. Have you tried your approach within larger organizations that are mid-transition with some agile and some non-agile teams? Apr 7, 2011 at 4:22
  • 1
    Actually I have. Adopting agile works as long as you do it in some group of people who are somewhat independent on the rest of the organization. It doesn't have to be a single team but then they shouldn't be in place where they need something for others like every couple of hours or so. In this situation the group can isolate themselves to some point, so they can work as they want, as long as they can build connections with outside world (even if "outside world" means team next door) which translate the way they work to the way the rest of organization works. Apr 7, 2011 at 8:31
  • Could you elaborate on your thoughts for situations are in the "middle ground" ? Not isolated, but not fully codependent either? Both of the current examples I have in mind are single or scattered teams that share an overall release goal, but are to various degrees isolated from their peer teams in the same 50-150 person organization. Apr 8, 2011 at 11:32

What planning and prioritization techniques are effective for Scrum teams and Product Owners working within an IT organization that uses waterfall planning behaviors at the release level?

If I'm understanding correctly, your situation is similar to mine - i.e., we work in organizations where SDLC/ Waterfall is the norm, but there's been a recent push towards agile in isolated pockets of the company. Even so, we run into road blocks of sorts when it comes time for the code to hit the production environment, because the Release team hasnt embraced the Agile methodology.

In these situations, as pawel mentioned, you can usually get the product owner to prioritize a list of 'stories' that define the release steps for a product. Its ideal to be able to work as an isolated team, but sometimes the red tape doesnt let you deploy code as a stand-alone release.

Depending on how much sway you have over the deployment process, the worst case scenario is that we can continue to develop via Agile in the QA / Beta environments and respond to real changes on this platform. When the official release date comes, all the stories can be deployed into the live environment.

Admittedly, this sort of defeats the purpose of 'Agile', especially if you're working on a product thats already available to the public. Another alternative might be to restrict the product release to a select group of users.

To be honest, I'm grappling with this issue myself, and would love to hear what others have to say as well.


We keep the releases very small -- to 3 months or less. This gives us a reasonable shot at creating a groomed backlog to represent the scope of the release. We actually use a Kanban process to flow the feature requests through research, specification, discussion, review, and approval status while keeping WIP under control. This isn't an ideal mix, but is (for the time being at least) a reasonable compromise between our company's Waterfall and Agile camps.

  • It sounds like you have more control over the release definition process than the team I'm looking at. Apr 12, 2011 at 3:28

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.