How to model a product development, testing and management into Scrum

eeshdayaumarikar

Hello everyone!

We are a startup having some products each of which has database, web and mobile apps and a set of servers. We are new to JIRA and to agile as well, but we are used to Trello. We want to manage our work better and track the timelines across modules as well as teams. 

Here is what we want to achieve using Jira - 
1. Track of proposals(new ideas to be converted to modules)
2. Tacking existing module's task and bug list
3. Time estimated vs time taken analysis after every week and use it to make better estimations in next week
4. Work done by each employee in terms of issues and time, understand if we need load balancing.

Here is what we have tried with Jira and the doubts that we came across with each step -
1. We have set up different projects for web, mobile and server part of each product i.e. 2 products make 6 projects and so on. (Is this approach correct? If now, how can we link the repositories in single project for single product?)
2. We have created issues in backlog and added some of them to active sprint. Product owner created stories and developer team lead created the sub tasks and assigned it to developers. Our testing team is going to add bugs, connect them to correct sub-tasks. We also created an automation rule where if all bugs are done, we can close the sub task. if all subtasks are done, we can close a story. Question is is this approach correct? This will require testing team to understand which bug belongs to which story/subtask which is difficult. The bug might be rooted deep in previously done sub-task. What should we do then? This approach feels complicated. Is there a better way to do this?
3. Till now we haven't used the epic or component. How should we use it? What can be called as epic? Lets say we have a login module that runs over web and mobile and uses the server and the db. Now is the login module a component or epic? Can web mobile server and db be called as components and if so, should we merge the projects related to one product into one?

Thanks in advance..! Waiting for community's valuable suggestions.

Nic Brough -Adaptavist-

Welcome to the Atlassian Community!

Rather than have me ramble through Agile principles and how Scrum mostly works quite well with Agile but people struggle to adopt it properly (I spend a lot of time with Agile, Scrum, Kanban, and DevOPs people and the general consensus is that a lot of people claiming that they're doing Scrum, Kanban, or Scrumban... well, um... aren't).

There's three key points that I want to try to frame the responses I'm going to write for your questions

• Agile is about delivering what the "customer" needs, not what they say they want at the beginning of the project.  It's about adapting to change.
• Jira is a Scrum and Kanban tool - it's got a lot of flexibility within those, which then allows you to do other things, but it won't do a lot of things people don't grasp are not Scrum or Kanban.
• Scrum is about time-boxing work and is intended for multi-functional teams.  At the very basic level, the process for Scrum is small.  Someone asks for something, the team chooses to do it in a sprint, and are capable of delivering the whole thing within a sprint.  

That last one is a bit more important - are your teams multifunctional?  During a single sprint, could your single team pick up a user requirement, analyse it, develop it, test it, and deliver something for the user to evaluate?

So.  Your questions:

>1. We have set up different projects for web, mobile and server part of each product i.e. 2 products make 6 projects and so on. 

This makes it sound like each part of a product is likely to be worked on by different teams.  That's not a problem, you just create an issue for each team to work through.

But, that does mean needing to think about cross-team stuff.  That's the point at which you reach for an Epic.  The Epic contains all the stories that need to go out to different teams.

> Product owner created stories and developer team lead created the sub tasks and assigned it to developers. Our testing team is going to add bugs,

Nope.  Scrum says nothing about sub-tasks, but they can be very useful for breaking up stories for all sorts of reasons.  But you say "developers" and then "testing team".  That's not a multi-functional team.

It's not one that can't do Scrum, if you redefine who "the customer" is, but you now need to think about boards, teams and having workflows that teams actually only look at part of.

You talk about raising new bugs - that works well for separated development and test teams. - development team delivers a product to the testers, the testers raise a new issue when they fail a test, and that bug goes into the developer's backlog for evaluation.

>we haven't used the epic or component.

Epics are for grouping stories/issues together, across projects.  Components are for sub-dividing individual projects (let your project owners define components)