Sprint Numbering across multiple (10+) Projects

The phrasing of this question only leads to more questions.

You keep using the term "project". How many products do you have and are the teams aligned with those products?

Why do you see the need to number or name Sprints?

Hi Joe, to get this out of the way... this is Scrum-but... but you know that already.

I've done both separated Sprints and a single Sprints as my teams grew. my advise (Not Scrum advise) would be based on how the projects/org is managed. 

1. One project, one dev team, one PM/SM per project, per sprint
2. Multiple projects, same team, same PM/SM, multiple sprints

It sounds like you have a small team working on many projects at the same time (Option 2). So my advice would be to focus on one project per Sprint. Shorten the Sprints to 1 week (to spread the value around). Make sure that each sprint has a clear goal. In the end, you will deliver more value this way.

If you have option 1, then I see no problem with keeping multiple Sprints but you really need to hire/assign a dedicated PM/SM for each project.

Next, just try it. Review after a number of Sprints and see if it worked. Think to yourself about why you are asking these questions (but no need to answer)

• why are you wearing so many hats?
• Can you really do a great job and be happy with the progress you are making?
• Without happiness and security, a team can't be successful 
• can your team do everything they need to deliver working software without you?
• Is this change to help you or the team?
• What does your team think?

If you do migrate this to a single Sprint

• How will the teams know what to deliver?
• Will there be releasable value at the end of the sprint?
• Will there be a solid Sprint Goal?
• Will each PBI be INVEST?

I don't know you or your team so I can only go off the comments raised. It feels like a change is required. If you implement Scrum (not Scrum-but), then your role is no longer needed but you are. Remember that Marketing is a proven field where Scrum works perfectly!

Happy New Year

There are 10 different products, all with new development (projects). The development teams are not aligned or working together.  The only consistent across all of them is myself and the Product Owner.

We use MS-TFS for Development, so the Sprints need to be named something unique.  The most common I've seen was Sprint + sequential #.  It also helps with reporting.   In addition to Sprint Retrospectives with Burndown reports, we do an entire Project Burndown Report after the release with the Stakeholders.  It shows the velocity of the project/product offering. 

Does anyone see a reason why they all can't be on the same Sprint #?

If you merge all this work into a single, cross team sprint then don't you take the burden of management the sprints and place that work onto every developer.

You can implement labels to allow teams to only see their teams work but what about reports?

• Teams Burndown chats
• Velocity Measurements per team
• Finishing and Starting a new sprint

Your backlog should be in the same place, but I feel if you have multiple independent (vertical stripes) work then they must all be on their own Sprint cycle. 

i'll give you a Scrum-but answer that is born from Scrum. 

If every team is working on a different product and different projects what good does it serve to have them all working on the same iteration numbers?  Wouldn't it be better to know that Team Alpha working on Product Unicorn is in Iteration 8 of their work while Team Charlie working on Product Megaplex is in Iteration 13 of their work?  Being able to see how many iterations of work have been done by the team on a specific project seems more in important than knowing that everyone is working on the 8th iteration.  I am assuming that you would restart your iteration numbers when a team starts working on a new project. In my project management opinion knowing that Team A needed 18 iterations for Project Unicorn and 15 iterations for Project Megaplex would be more useful in the long term from a project management perspective because it would give me the ability to maintain and compare Gantt Charts for that team.  As for the actual name of the iterations, I would suggest that you name them <Project Name><sequential number> (i.e. Unicorn08, Unicorn09)

Now, why is my answer born from Scrum.  Because it is all about providing visibility and being transparent about the work that is being done by the team.  Don't try to obfuscate information with common naming but try to broadcast information with meaning. I have worked with actual Scrum Teams doing Scrum that used random name generators for their Sprint names (we used Jira).  The information that was of importance is the progress made towards satisfying the Product needs as indicated by the Product Backlog. The Scrum Guide doesn't say anything about naming Sprints.  Tools require that so that they can segment data properly.  So name your increments anything you want. In fact, I would encourage you to let the teams decide what they want to name their increments. It gives them another sense of ownership of their work.

You state that one of your roles is Scrum Master. I would suggest that you spend some time actually reading/studying the Scrum Guide (https://scrumguides.org/scrum-guide.html) so that you can start to understand Scrum.  Even in a Scrum-but world like yours, the Scrum theory, principles, artifacts, and events could be useful to you. 

There are 10 different products, all with new development (projects). The development teams are not aligned or working together.  The only consistent across all of them is myself and the Product Owner.

If you truly have 10 products, you would ideally have 10 Product Backlogs, 10 Product Owners, and 10 teams. However, 10 products seems like a lot, to me, especially for a small organization. I'd probably want to rethink what you consider a product and if techniques for managing a product suite or a portfolio of products would be beneficial to helping to add a little bit of structure. Some alignment where appropriate would go a long way to helping organize around products or groups of related products. You may be able to reduce the number of teams and perhaps Product Owners by organizing around suites and portfolios of closely related products.

We use MS-TFS for Development, so the Sprints need to be named something unique.  The most common I've seen was Sprint + sequential #.  It also helps with reporting.   In addition to Sprint Retrospectives with Burndown reports, we do an entire Project Burndown Report after the release with the Stakeholders.  It shows the velocity of the project/product offering.

This seems to be a tool limitation. I've never used TFS, so I can't be sure what is considered a good practice. I'm most familiar with Jira, which also uses a Sprint name. The teams that I've worked with use a very short summary of their Sprint Goal, the start or end date for a Sprint, the date range for the Sprint, or a name based on a theme of the team's choosing. I would recommend thinking about who would see the Sprint names to decide if you want a more "professional" or a more fun name.

I'll also add that Scrum is based on one product, one team. The Scrum Guide has some information about multiple teams working on a single product. Scaled frameworks like LeSS, Nexus, and Scrum@Scale offer information for when you get to 3+ teams working on a single product. However, in a case where you have more products than teams, I'm not sure that Scrum or the scaled Scrum frameworks will be of much use as this isn't the type of problem they are designed to solve. It may be possible to apply Scrum ideas, but you probably won't have Scrum.

I guess I need to explain our environment and clear this up a bit.  I think the point of my post has gone completely off the rails.  



Yes, we have 10 actual customer facing products that are worked on by 10 different development teams.  Those 10 fall under me and one Product Owner.  I am in 10 scrum meetings a day, all different people except the PO and Myself.  So, when I say a small house, it's a relatively small company with 36 on-staff developers.  Some of the separation is due to coding language and business knowledge.  I don't control staffing/hiring so I work within the constraints I have.

In TFS, each one of these Products have their own site.  So if I say Sprint #1, the TFS Query automatically puts that in it's site.  So:  Product 1\Sprint 1.  Which is how I run reports via MS-Project for Retrospectives.  TFS is a bit different as it's also the "warehouse" for the developer's check-in code.

I believe I have my answer as far as naming goes. 

I wish I could go full Scrum to be honest, but when the boss requests [blank], you do [blank].  When I came into this position in 2017, there were 77 full Projects in "on hold" status operating in "agile" methodology, but the only thing Agile about it was the use of the word Sprint.  It's been an uphill battle.

I am in 10 scrum meetings a day, all different people except the PO and Myself

What Scrum meetings?

If they are Daily Scrums, why are you and the PO there at all?

The daily standups/scrums?  Why wouldn't I be in those meetings?  

Given the new information, the situation makes a lot more sense to me.

The original problem of naming/numbering Sprints is totally irrelevant. That's entirely a tool configuration issue and has nothing to do with Scrum. In fact, the Scrum Guide doesn't mention anything about an attribute to identify a Sprint from any other Sprint.

However, there are still some issues here. It's not clear exactly what your role is. If your role is that of a Scrum Master, I'm not sure that you can effectively coach or facilitate 10 teams. Depending on the team's maturity, experience with Scrum, and how they are organizing their events, I believe that the number that a single person can coach falls between 1 and 4. Some people suggest a smaller maximum - LeSS, for example, calls for 1 Scrum Master for up to 3 teams.

I don't think that the mindset of "I work within the constraints I have" is an appropriate mindset for someone in an agile coaching position and seems to be more indicative of a project management approach. Someone in a coaching role should be working to make the problems and potential solutions visible and work with the organization to take steps to get to a better place. Doing this requires coaching and facilitating on a team and organizational level, and perhaps even an individual level.

The fact that there is only one Product Owner for 10 products is also concerning to me. It does depend on how closely aligned those products are with respect to their functionality and their stakeholders. However, supporting 10 different teams can be extremely taxing. Although the Scrum Guide suggests one Product Owner per product, I think that there are opportunities to look at one Product Owner per product suite or product portfolio. It isn't easy, but sometimes it's the reality that we need to work in until we can get to the ideal place.

Along the lines of what Ian Mitchell suggests, I'm interested in what these 10 meetings per day are. If they are the Daily Scrum, I do see the value in the Product Owner attending, at least sometimes. The Scrum Master may also be asked to facilitate. However, a mature team should be able to handle the Daily Scrum on their own generally. I'm of the thinking that the only event that is best regularly facilitated by the Scrum Master is the Sprint Retrospective.

As far as the uphill battle goes, I'd want to know if Scrum is really appropriate for your environment. Scrum is definitely not designed for your environment, although you may see some benefits from some of the practices. I'd recommend looking at other methodologies and frameworks and rolling something better suited for your environment, at least in the current state.

The daily standups/scrums?  Why wouldn't I be in those meetings?  

The Scrum Guide says: "The Daily Scrum is a 15-minute event for the Developers of the Scrum Team".

Are you and the PO members of each Development Team?