I'm working on transitioning my team's project methodology from the waterfall model to an Agile one. I'm looking at the Scrum framework as a starting point.

Currently, we have these Joint Application Development sessions where team gets together with our stakeholders to define requirements. These sessions are often used on "traditional" IT government projects, so I'd like to keep them to lessen the friction. However, I'm not sure to which Scrum ceremony these meetings map, or if it would be better to sell the stakeholders on getting rid of them.

  • 2
    Good question, but please don't use an unlinked intialism for Joint application design, which isn't a scrum term. – Nathan Cooper Dec 20 '16 at 22:36
  • @NathanCooper: I know that's it's not a scrum term. – J. Bauer Jan 30 '19 at 2:20

Requirements gathering is performed throughout the lifetime of the project by the Product Owner. Typically, much of this will occur before the Development Team begins sprinting, but at the end of every Sprint, a Sprint Review meeting is held, allowing the Product Owner and stakeholders to view the current state of the project and the product. This then allows the requirements to be refined.

As for official, formal meetings that are a part of Scrum, there are only those from the Scrum Guide. The daily standup, the retrospective, the planning meeting, and the review. Anything beyond this is part of a specific organization's procedure, not part of Scrum itself.

  • I know that, but I wasn't sure if there should be a formal place for Joint Application Development sessions, given that government projects love them. – J. Bauer Nov 20 '16 at 15:43
  • @J.Bauer Not officially, no. I've updated my answer. – Sarov Nov 20 '16 at 18:23

So in this case JAD is a version of requirements gathering. The PO can schedule these whenever they like in-order to bottom out their requirements and improve their epic / user story details.

However the Scrum team should be protected from these as much as possible. If they steal the teams development time on the current sprint then they would break the terms of scrum.

It may be necessary to consult with the scrum team to clarify some aspect of the requirements ... but it should be in exceptional cases only.


On Agile teams, you typically have 5 layers of planning: enter image description here

These layers are usually tied to a timebox, or what is often referred to as a 'planning horizon,' e.g., the amount of detail we will go into at this moment is based on the timeline of our goals and expectations. The fidelity of our discussions go from a mile wide and a foot deep for the product vision, to 100ft wide and 1000ft deep for each iteration.

In Scrum, requirements discussions occur at all levels of planning and happen on a daily basis. Cadence-based ceremonies set clear expectations for when the larger discussions happen. In Scrum, you typically have a release planning event every few months, with sprint planning every 2-3 weeks, and backlog refinement sessions ~ 2 or more times a sprint, and then daily standups.

Most Scrum teams start with an iteration 0, which is not a sprint, and during which the team continues to flesh out the product vision, product roadmap, and release planning activities for the first sprint. This is usually done through workshops and activities, over the course of a few days. I recommend checking on Jonathan Rasmusson's The Agile Samurai, as it entails a lot of great material in setting up an Agile team using an 'Inception Deck.'



Allow me to ask why you consider moving to Scrum? The transition to Scrum is a much harder one, compared to a transition to Kanban. In this article we talk about implementing a Kanban Work Breakdown Structure using the Kanban method and executing the work items in the fastest way possible. In other words, we propose a transition from Waterfall (WBS is a typical waterfall approach) to Kanban, which is a lightweight agile approach.

This approach not only allows you to keep doing what you've been doing (and continuously improve) but it will speed up things ridiculously (up to 700%). I hope this doesn't sound like a sales pitch, because it's not, but Kanban can really do miracles for you.

  • 2
    I feel this answer doesn't address the question, though you bring up a good point about considerations when choosing a process methodology. – neontapir Jul 12 '17 at 21:50

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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