Agile Sprint Planning for Cross-Functional Teams (UX, UI, Dev) [closed]

Question

We have recently started using Agile methodology implemented with Jira. We are struggling to decide how best to arrange Sprints, Epics, Stories, etc when working across different departments.

For example, let's say we're going to make 'Feature A'.

At a basic level, sufficient for this question, 'Feature A' needs to go through four departments/stages:

1. UX & Wireframing
2. Design
3. Back-end Development
4. Front-end Development

We are a small company working on a single Saas Product, with 2 or 3 individuals in each of the above teams.

Do we give the 4 stages their own epics, or do we give them their own stories/tasks within shared epic, or something else (like separate themes, initiatives, or even projects)?

I know there is element of "It depends" and subjective preference, but am hoping there are some opiniated "default" suggestions that might guide us on what is going to work best for most situations.

One motivation for making this decision early is generating informative product roadmaps for stakeholders that show UX, Design, and Development all in one place, that can be generated from Jira, rather than manipulated separately.

I'd really appreciate your comments and suggestions. Let me know if you need any clarification.

Answer 1

Don't Overthink The Process

The first principle in the Agile Manifesto is "Individuals and interactions over processes and tools".

Furthermore, the KISS and YAGNI principles apply just as much to delivery processes as they do to code.

Two questions I find useful to ask when looking at any aspect of a delivery process:

1. Is It Necessary?

   This can be a useful starting point to questioning whether some aspect of a process has any tangible benefits to the team, project or stakeholders; if you cannot clearly identify tangible benefits of doing something, particularly anything which might potentially create additional complexity or cost additional time, then most likely you simply don't need it and shouldn't do it.

2. How Much Is Sufficient?

   This can be a useful way to draw a line in ensuring some aspect of a process is only followed to the extent needed for those involved to be able to get on with their job, anything more is likely to be superfluous.

---

To answer some of the specific points on the agile planning tool, I'd recommend initially starting out with a single project and no epics:

• Projects: It sounds as if the organisation has a single product, and indeed that the delivery team itself is split into different departments, which could be a danger in becoming a barrier which probably needs to be weakened rather than reinforced in a project planning tool like Jira.

  I'd recommend initially attempting to avoid these barriers by avoiding any kind of separation between the departments in the tool, particularly avoiding multiple projects, instead encouraging all departments to focus on a single shared project for the product with a single backlog, as a way to encourage those departments to collaborate more closely with each other, having visibility of each others' work all in the same space which they use each day.

• Epics: Unless epics represent something specifically useful and meaningful in the context of this project, then they're probably not needed.

  Epics might sometimes be useful to represent something which had been agreed with senior stakeholders before a project started such as a total project budget or a major calendar/release milestone, or a bullet-point on a roadmap or quarterly report back to senior/top-level stakeholders. I would not usually expect epics to be particularly useful to the delivery team or their day-to-day process.

• Stories: User stories are a description of a feature from a user's perspective -- it sounds as if the journey of a feature from its initial inception up to eventual release/delivery would involve multiple departments, so I would suggest having stories shared between departments (on the single project) so that any work (tasks/sub-tasks) attributed to that feature remains under the umbrella of that story -- i.e. a story being the single focal point to understand the progress and remaining work needed for it to be delivered into production..

• Sprints: A sprint is a time window (usually a few weeks), with Scrum being about commitment and reliability - ideally all items in a sprint at the beginning should be 'Done' (or close to done) by the end.

  Sometimes it's necessary to bring items into a sprint which require the development team to investigate a lot of unknowns -- these are also fine, but they generally require time-boxing ("Spike") to prevent the item from wrecking the sprint.

  Sprints typically work well for fully-elaborated stories which are ready for development (See: Definition Of Ready) and able to be estimated with reasonable confidence; Scrum falls apart when a lot of time is soaked up in ways which weren't anticipated or planned at the start of the sprint.

  With this in mind, I would avoid trying to use sprints for stories which aren't in a 'Ready for Development' state yet. This usually includes anything resembling UI/UX design work, business analysis or requirements capture -- the nature of this kind of user-facing/stakeholder-facing design work often means it lends itself to a more free-form way of working, in order to refine a story to the point that it reaches a Ready state

  If some people are responsible for stories which lead up to Definition Of Ready, then it may be worth merely leaving those items on the backlog with a 'status' indicating that those stories aren't ready yet, then allowing those people to follow a more 'Kanban'-esque process instead of attempting to shoehorn them into Scrum. (You could perhaps create a separate Kanban board for those items)

---

A key aspect of agile is change. Agile doesn't prescribe any kind of process; it certainly doesn't advocate for tools to control a process. It merely calls for something minimally useful, only adding complexity and tooling when a clear need arises.

Don't fall into the trap of attempting to let the tool determine the team's ways of working - such thinking is the antithesis of agile; instead, start with something minimally useful (perhaps the default Scrum template), then let the team determine the best way to evolve it later.

I'd recommend inviting the team to attend regular ceremonies to reflect and feedback on the process and usage of the tools to seek ideas for improvements from the people who are using the tool day-to-day - allow this to decide if/when something about the tool's usage needs improving.