Planning sprints for different phases of product development

[Albert Christof]

Hello All,

I'm new to the domain of agile/scrum world and need some guidance on few general queries related to setting up a scrum oriented workflow to drive and deliver projects.

Scenario - Team has to work upon and deliver multiple automation related projects, covering the traditional phases like plan >> build/develop >> test/qa >> release. Based on business priority and complexity some products may get released sooner than others.

Q1 # How do I define sprints to cover different phases of product lifecycle ? Should it be separate sprints for each lifecycle stage or common sprints with standard duration of 2 or 3 weeks, but stories should be clearly flagged based on the phase it belongs. I'm more inclined to second option as having seperate sprints for each stage may not fully and optimally utilize the capacity and capability of the team.

Q2 # In continuation of above query, if stories from these different phases of development cycle are driven in common sprints, how to categorise them on Jira tool, since I will like to report on how many stories are defined for each stage of each product and how things are progressing for each product

Q3 # Can stories of multiple projects be driven is common sprint ?

Q4 # With different products having different delivery timelines, how to plan release sprints or should I use a common retro meeting to release products as and when they are ready ?

Looking for kind guidance on above queries.

Thank You,

Albert

[Nic Brough -Adaptavist-]

Ok, so I think you're not quite fully understanding some of the Agile ideas, and you're carrying over waterfall principles into your thinking about Scrum.

A sprint is a time-box for a team.  During any given time-box, a team commits to completing a delivery of one or more stories.

The product life-cycle is irrelevant to that.  A story is rarely "the complete product" but it should be a deliverable thing that shows progress towards it.

So

Q1.  You don't. 

A sprint is a time-box during which your developers should build, test and deliver something that meets the needs defined in a story. 

The "phases of development" that you're carrying over from waterfall are irrelevant to the sprint, because all of them happen within the sprint - the team is given a story, and they plan, develop, build, test and release it within the sprint. 

Q2.  This question does not apply once you understand that your phases of development are the wrong way to think about the working process.

Q3.  Yes

A project in Jira is a container for issues, it's mostly about gathering similar issues together and having them work in the same way (workflow, people's permissions, who gets email and so-on).  Most people will align projects with a real-life thing such as a product that needs development and/or maintenance, or a team, or a specific purpose, but that is not a requirement.

For Agile teams, the board is the important thing.  A very simple way to express it is "Board = Team".  A team should work off a single board, one which shows them everything that they are responsible for dealing with.  That board can draw in whatever issues you want, from any project.

Often, you'll see boards that are simply "project = xyz", but that's a simple default and based on the way people tend to think about who should be doing what (it's an easy way to think - project x belongs to team y.  Nothing wrong with that way of thinking, it's perfectly logical and intuitive).  But you absolutely don't need to think that way.

When I started doing Scrum <mumble> years ago, we built a board that said "project = X or label = z" because our team had its own project, but often needed to work on issues in projects that were not ours.

Q4.  So now you're going up above Scrum and looking at the wider picture.  The answer to that depends entirely on how you want to work at that level.  (Forget "release sprints" though - that's not Agile)

[Albert Christof]

Thanks a lot Nic.