Planning sprints for different phases of product development
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
You are trying to implement waterfall using agile and Sprint terminology. If you search these forums you will find many posts about that topic and they all basically have the same advice. Waterfall and Scrum are different and attempts to force one into the other will not result in Scrum.
The following is VERY simplified and my opinion but hope it helps.
In Scrum, every Sprint focuses on building a usable increment of a Product. Each Scrum Team focuses on a single product. Each Product has a single backlog made up of items that represent work needed for the Product. A Scrum Team is made up of a Product Owner (responsible for determining the direction the Product will take), a Scrum Master (responsible for the helping the organization and Scrum Team appreciate the Scrum framework), and Developers (responsible for the work to turn Product Backlog Items into usable increments). Developers create a Sprint Backlog by picking items from the Product Backlog that they feel can be done in a single Sprint. A Sprint Goal is crafted to help focus the Developers on the most important work and to guide them in accomplishing the goal of creating a usable increment. A Definition of Done is crafted by the Developers to communicate exactly what they mean when they say that they are "done with this work". All work needed to deliver a usable increment is done within the boundaries of the Sprint. A Sprint is a fixed length time box of no more than a month.
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.
All of the activities you listed may occur during the Sprint. However your organization may choose otherwise. Each increment is usable and could be delivered but there is nothing that says it has to be delivered. Multiple increments may be accumulated before the actual release occurs. That is entirely up to your organization to decide based upon factors that matter to you.
Scrum is a framework so it does not dictate process. The process you want to use is again entirely up to your organization.
Scrum is not the same as agile. Notice I used lower case a in agile. That is because agile is a verb that describes an entity's ability to adapt quickly to change. The term Agile is a marketing term developed by people/companies that wanted to commercialize the Manifesto for agile software delivery. You can't do Agile, but you can be agile.
I suggest you revisit all of the material you may have read about Scrum or agile practices but do not try to equate things to waterfall or the way you have always done things. You should also look at this information from the scrum.org site (https://www.scrum.org/resources/what-is-scrum). You may want to consider some of the suggested reading material for the certifications provided by this organization. This should help you with learning more about the Scrum framework. As for learning more about agile, there are multitudes of information available from the Agile consultants. But my suggestion is to learn about empiricism and how it can be used for business decisions. After mastering that, it will help you better understand what your needs are.
You do not start doing Scrum. You evolve to Scrum. There are many ways that an organization can become more agile, including ways that work within waterfall or long held Project Management practices. You also do not start doing Agile. You have to adapt to become more capable of adapting to change as it occurs which helps with your agility.
I'm again going to say that all of the above is me voicing my opinions in a short format. (Yeah, that is short). I'm anxious to see how others respond. That is how I learn to be more adaptive.
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.
Who actually wants Scrum to be implemented in your situation, and why? What outcomes are being hoped for?
Two things to consider regarding empiricism:
- An agile workflow doesn't involve driving, it involves pulling
- Projects aren't delivered, value is.