Skip to main content

Length of sprint

Last post 12:59 pm November 21, 2018 by Steven Busse
4 replies
09:50 pm November 20, 2018

Hi

I am working for an organisation that is attempting to implement more agile processes.

Currently, we have:

1. One month sprint cycle

2. Daily stands up last an hour

3. All JIRA items are tied to an EPIC that is an overall priority for the customer

4. We have about 20 developers working on the sprint and that’s the number of people who join the calls 

5. Sprint planning literally takes a whole day with all 20 developers in a meeting because we are planning a whole month’s work

For context, we have about five different products - all somewhat related - but different at the same time. Everything is within one JIRA queue, although labelled differently.

I’m thinking this is madness :) I was thinking that we break that one month sprint into two two weeks, that’s should lessen the time taken for daily stand ups and sprint planning. Also, if we break the products into each sprint (so we have five sprints for our company) then that should reduce the number of people on each call and provide more focus.

What do experts think here?


10:22 pm November 20, 2018

I will start with suggesting that you "rtfm".  (No offense meant.)   https://www.scrumguides.org/scrum-guide.html

The Scrum Guide states some boundaries from which I think you would benefit.

I suggest you work on the team size first.  Twenty people is way too many people to work effectively and gain consensus.  It is possible to have multiple teams work from the same product backlog and given your makeup of the product backlog, it should be very easy for you to have multiple teams work on a separate product which as you suggested could result in splitting the large team into multiple smaller teams. 

Daily Stand Up of 1 hour is not a daily stand up and Planning for an entire day is not usual either. Read the section in the guide about the Scrum Events paying close attention the purpose and suggested duration of each. Remember that the Scrum Guide uses a one month sprint for the basis on all of their suggested durations. Make sure to do the math to adjust times to fit whatever duration you end up settling on. 

I also work where we have "product backlogs" that contain more than one product.  I actually call them team backlogs instead.  It can be managed but you have to make good use of refinement, backlog ordering and sprint goals to help focus the team on work that will deliver value when that value is needed.

The Scrum Guide states that sprints should be no more than 1 month, so you are doing that part right.  However, everywhere I have worked has found that 2 week sprints are more manageable. 

I will also suggest that you might benefit from bringing an external "expert" to help your organization.  There are many agile coaches that can help you.  And I have found that when a company is paying someone a consulting fee to be an expert, they are more likely to listen to them than to someone that is already on their payroll. 


12:03 am November 21, 2018

As per scrum guide, effective team size in Scrum is 3 to 9 team members. Your team size is an issue here. 20 is way too much.


06:06 am November 21, 2018

Adopt the practices that suits your team the best , Ask yourself do you actually need scrum. don't follow scrum for the heck of it, which is now a days a trend.

20 people is way too much. 


12:59 pm November 21, 2018

As Daniel pointed out: Check the Scrum Guide, so you can start doing Scrum, which you don't, as:

1. One month sprint cycle

- Max is four weeks. Why might this be?

2. Daily stands up last an hour

- Max is 15 minutes. Why might this be?

4. We have about 20 developers working on the sprint and that’s the number of people who join the calls 

- Max is 9. Why might this be?

At products and teams of this size, you should think about implementing one of the many approaches to scale scrum like Scrum of Scrums, LeSS or Nexus (by scrum.org). Implementing such a scaled approach comes with the additional complexity of managing dependencies between teams, product backlog items and the concurrent work on them, but if done the right way, it still won't slow you down as much as staying at your current scale of sprint/daily/team does.

Your organization should think about the following questions:

1. How could those 20 developers assigned to 3-4 teams cross-functional teams, being able to independently work on the product backlog?

2. How can product backlog items be assigned to those teams without creating dependencies between the work of those teams

3. Could the previous answer provide ideas for a better use of epics?

4. Could the previous two answers provide ideas on how to answer question one?


By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your Scrum.org member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use

Scrum.org may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Scrum.org Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by Scrum.org may have their access revoked at any time, without warning. Scrum.org may, but is not obliged to, monitor submissions.