Skip to main content

scrum ceremonies to be consider in velocity

Last post 02:10 pm June 2, 2020 by Ivan Traveso
4 replies
08:01 pm May 30, 2020

we have a 2 week sprint, in which we spent a total of 5.15 hrs in sprint ceremonies

15 mins : DSM 

(15*5)= 75 min ( 1 hour 15 mins)

1 hour = planning

1 hour = refinement

1 hour = review

1 hour = retrospective

-----------------------------------------------

These 5.15 hour the team invest are part of my current sprint which is ongoing. They also do brainstorming session once they receive some story dump in refinement session. so on top of 5.15 hours, please include another 2-3 hours in a week. They need these hours to brainstorm internally to see the flow and come up with the question. So while calculating team velocity, how these should be considered?


08:32 pm May 30, 2020

What problem are you trying to solve? Why would the things you mention figure in a velocity calculation at all?

Other things to consider:

- Are 5 Daily Scrums over a 2 week Sprint adequate? How are team plans developed for the next 24 hours?

- Are the other events long enough? They seem rather abbreviated, and perhaps this explains why you refer to them as "ceremonies".

- How does a "story dump" contribute to refinement? Is the quality of discussion adequate, given that team members must spend a further 2-3 hours per week "brainstorming"?


09:47 pm May 30, 2020

Given a two week Sprint, I would expect the maximum time to be 150 minutes or 2.5 hours (15 minutes * 10) for the Daily Scrum, 8 hours for Sprint Planning, 4 hours for Sprint Review, and 3 hours for Sprint Retrospective. The Scrum Guide does suggest that these activities may be shorter for shorter Sprints, and some people do suggest a proportionally shorter event duration. For a two week Sprint, that would likely be closer to a 4-hour Sprint Planning, 2-hour Sprint Review, and 1.5-hour Sprint Retrospective. Overall, I would expect between 10 and 17.5 hours for the Sprint events. The time for Product Backlog refinement is more of a function of Development Team size rather than Sprint duration.

However, all of that is a tangent. None of it has to do with velocity. If you size your Product Backlog Items in Story Points, velocity is simply the sum of Story Points associated with Product Backlog Items that were Done in the Sprint. The amount of time in events and refinement doesn't have any bearing on this. Since you aren't working on getting Product Backlog Items to a Done state during these events, only the remainder of the time that you are working on them will contribute toward your velocity. Since the amount of time in the timebox for each event is consistent across Sprints, it becomes mostly irrelevant toward calculating velocity.


03:49 pm June 1, 2020

A team's velocity is measured by the number of Product Backlog Items(PBIs) that can be completed to deliver value.  So all of the time needed to deliver those PBIs is treated the same.  That would be time for refining, coding, testing, reviewing, retrospecting, analysing, etc.  

rapidity of motion or operation; swiftness; speed:

That is the first defintion provided for Velocity at dictionary.com.  Velocity of a car is measured by how many miles/kilometers can be traversed in a specific amount of time.  Velocity of a Scrum Team is measured by how many increments of value can be completed in a specific amount of time. 

@Ian Mitchell and @Thomas Owens both mention that your team seems to be undercutting their time needed in the events (not ceremonies).  I'm going to assume that is because your organization sees any activity that isn't associated to someone at their desk writing code as wasteful and unnecessary.  So you try to keep things that would show up on a calendar as short as possible. This practices actually hides information rather than making it transparent.  Everyone knows that developers will talk to each other about the problem they are working on so why try to hide that?  In my opinion showing the carefully thought out execution of problem solving shows more efficiency and desire to be as effective as possible.  That leads to less costs and better results.  What company wouldn't want that to be the case?

So, as Scrum Master you should be helping your organization understand that your Scrum Team will be doing as much as needed in what ever way they feel is best to deliver the highest quality product in a manner that is sustainable over time. 


09:07 am June 2, 2020

Hi Rhea,

I would say that if the allocated time for these ceremonies doesn't change from sprint to sprint (ie you spend around 5.15 h / sprint in ceremonies) then this is won't have an effect to forecast the velocity of the team, since looking at the velocities from the previous sprints will reflect how much work the team could deliver including these 5.15h for the ceremonies.

At the end of the day, the velocity is just a measure of how much work can the team as a unit deliver on a given sprint. During sprint planning we can forecast what would the ideal velocity be for the sprint based on previous data and the expected capacity of the the team, and this can be used as a guideline by the team to create their sprint backlog to realize the sprint goal.

I hope this helps.


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.