Where would Joint Application Development sessions fit into the Scrum framework?

Question

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.

Answer 1

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.

Answer 2

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.

Answer 3

On Agile teams, you typically have 5 layers of planning:

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.'

https://www.amazon.com/Agile-Samurai-Software-Pragmatic-Programmers/dp/1934356581/ref=sr_1_1?ie=UTF8&qid=1514494663&sr=8-1&keywords=the+agile+samurai

Answer 4

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.