Managing small + large tasks on a big website with Scrum

Question

We're a small team of 4 developers who manage one large website and a group of minisites/mobile apps. We've used JIRA/Agile and Scrum, as best we can, to manage the workflow for the last few months.

However we're struggling to manage a backlog which consists of;

• Small tasks (move a button, change a word)
• Large tasks (a new section of features)
• Non-related tasks (build a new minisite)

Now our main project has versions (and we're talking about milestones), and the mini projects rely on versioned subsystems from other projects. We're finding it very difficult to have a sane meeting with a disorganised backlog.

How do we manage small tasks and big ideas in the same list? How should project boards, epics, stories and sub-tasks relate to milestones, versions, large features and small tasks?

As an inexperienced ScrumMaster I feel like I'm letting the side down. The requests coming into the team are sane, the developers are skilled, but I'm having trouble bridging the two!

Answer 1

How do we manage small tasks and big ideas in the same list?

In Jira Agile you can create epics to represent large stories. When you decompose this epic you can write several stories with the same epic as the parent. For smaller tasks, you can create sub-tasks under a story.

...manage one large website and a group of minisites/mobile apps.

In the above situation, I will create 3 projects:

1. Website
2. Minisites
3. Mobile

Because you have a single team to do all these projects, you need a single Board. In JIRA/Agile when you create a Scrum Board, it can contain one or more projects.

How should project boards, epics, stories and sub-tasks relate to milestones, versions, large features and small tasks?

Fields such as the following are available in Jira:

• Affects Version/s
• Component/s
• Fix Version/s

You can hide/show the fields, as needed, in the Field Configurations screen.

When you create the stories/bugs, you can assign the Fix Version, for example. However, only add those fields that you are committed to maintain.

When you are doing backlog refinement or Sprint Planning you will find that the Quick Filters are very useful to look at the subset of issues related to one topic. You can set up Quick Filters by Project, Version, Component and so on.

Answer 2

+1 on Ashok's advice to decompose the Large Web tasks into smaller tasks. Using the Epic feature will work well.

This still does not address the "what do we build/do". Something that doesn't get covered in the standard Scrum training is pretty much how to get to a "well-ordered backlog".

While we are getting good at doing story point estimating for the "cost" to build a feature, we forget we should also be assigning value to the features. This is something the Product Owner needs to do. They assign value to each task based on some pre-determined system.

Once you have Value and Cost, then you can make an intelligent decision about what gets done first. The high Value, low Cost items will be the things that get done first (provided they have no dependencies).