Borrowing from one of the elements of the JIRA ticketing system, there comes a time when the influx of development requests very obviously is epic in proportion, and should be recognized as such. Any member of the team should be able to call this out, “hey, that’s Epic”, and help drive an Epic Meeting.
Sometimes Epics happen naturally, especially in product development-oriented organizations. A new product is definitely a new epic, and calls for a discussion on the overall goals of the product and an initial approach to its design. This should be hashed out well before development, individual tickets, and sprints start. Sometimes, the realization that an Epic is happening doesn’t manifest itself until the weight of requests pressures the need. A manager may recognize it during discussions with developers, “well, to implement this request, we’ll have to change not only the front-end, but the APIs, the back-end database, and everything that touches it”. Or, when a developer sees a pattern of requests that repeats itself, or even more glaringly, creates contradictory demands on a subsystem. “Wait, we can’t fulfill both A and B with the same method signature – something has to give, or be redesigned”.
What should be done in an Epic Meeting? Once you’ve recognized an Epic point, how do organize an effective epic meeting? Here’s a suggested agenda, and it may occur over one or more meetings. I suggest capturing all this into a shared Epic Document after everyone has discussed and hashed out each of the items:
- Goals. What is the goal of this overall epic?
- Strategic/Mission Fit. Discuss the organization’s overall mission and vision statement as well. While discussing the epic’s goals, reflect on how well they meet your mission? Should the mission be redefined too?! Well, discuss that, and branch out to develop a new mission statement too, if necessary.
- User Agents/Personas, User Stories. If the team has already developed a catalog of Personas, reference them. If the Epic requires new user agents, this step back to discuss them and define them as well. Then, flesh out some initial user stories. This is perhaps led by a Business representative, perhaps a product manager, or anyone with a vision of what they think this epic involves from an end-user perspective. In an early Epic meeting, these user stories will just be sketches, not fully-fleshed out scripts. That’s okay, don’t spend too much time and get stuck in analysis paralysis.
- User Interface Mock-ups. Again, just sketches – constrained to a dinner napkin or back of an envelope – not high-fidelity wires or such. Anyone can contribute their ideas of what they think an epic product should look like. Share ideas and excitement about how it all appear.
- Questions. Questions are bound to emerge in the course of any discussion of epic proportion. Be sure to capture these questions, for follow-up later.
- Out-of-Scope Items. This may not come up in initial epic meetings, but will eventually emerge. The excitement about new epic development may lead to a wide range of wild ideas, many of them not feasible, many of them not even relevant to the original mission. Humble down the excitement a bit by reflecting on the mission statement and see what epic items resonate. Discuss with the actual developers the feasibility of implementation – of course, given enough time, developers can implement most anything, so toss some anticipated timelines into the equation. Keep an epic’s objectives down to a single quarter in the calendar year, for example.