One of the things we do as company staff, who are involved in projects, is to justify our productivity as a result of the number of hours we have worked, the amount of money we have spent (on the project), and the effectiveness of the processes used in delivering our projects.
This is particularly important when starting the implementation of a digital transformation initiative or using a new framework to deliver cutting edge technology. At the early stage of every project (regardless the industry), normally the team is new and going through their forming and storming stage. Do not be surprised if you face a lot of challenges like I have experienced, especially when you have a PMO office which always push for accurate resource management and accountability. Trust me, at this stage, you will find yourself in a team that is facing a lot of anxiety and uncertainty.
This is not the best time to determine your team velocity. Any any plans you make at this early stage will normally be flawed and might not show your real team's sprint velocity which is a function of your team's Focus Factor. As a Scrum Master, you have to encourage your team to be self organising and determine their strengths and output rate. This is normally done after the 3rd to 5th sprint. Once you determine this, it is easier to determine team Capacity Planning.
I have been asked many times, why we need to determine our team capacity, while the Agile Manifesto states that there is preference for a "Working Software Over Comprehensive Documentation" and the need for teams to "Respond to Change Over Following a Plan"... Whatever method you use in a project, the truth is that you need to know what you are producing, the risks involved, and the metrics to measure if you are as productive as you can or not. So, depending on the number of team members you have in your Scrum team, you can effectively determine the Focus Factor (which is the team's ability to remain focused on the sprint goals without any other distractions), by using the below formula:
Focus Factor = Sprint Velocity / Team Capacity
Sprint Velocity is the average completed (estimated) story points over the past three to five iterations. Team Capacity is a product of the total number of Scrum team members multiplied by the number of team productive days.
Here is a quick example for clarification: If your average sprint story point is 32, and you have 6 team members who are available to work (8hrs/day).
Focus Factor will be: 32 /(6*8) = 0.67
So, for a Focus Factor of 0.67, to now get the effective Team Capacity, it is the Focus Factor multiplied by the total number of hours the team is available for work. For a 2 weeks sprint (say it from 1st January), it is 10 days taking Saturdays and Sundays off (if applicable).
Team capacity would be 0.67 * (6*8*10) = 321.6 hours
From the calculations above, this team will have 158.4 (480 - 321.6) (Total working hours of the team in a Sprint - Team Capacity) hours for Sprint Planning, Daily Scrum, Sprint Review, Sprint Backlog grooming, Sprint Retrospective, Breaks, team meetings (story point clarifications with PO) and other needs that arise on the course of the sprint.
It is vital to always consider your Team Capacity (a direct function of the Focus Factor (normally between 0.6 to 0.8)) when committing to Sprint Story points! Otherwise, you will be setting an unachievable sprint target for your team. With Team Capacity, you can fairly predict the number of hours your team is actively working on committed product increment, their ability to remain focussed on the sprint goals without any other distractions - and also know when you have a healthy team.
Thank you very much for reading!
Although there are some learnable aspects of leadership, leadership is often identified as something that comes naturally to certain personalities. Therefore, it is no surprise that certain people can act as better servant leaders and better Scrum Masters.
Let's look at some characteristics that will help you master with your Scrum Master Role.Join This Discussion >>
Hi there, Have you ever wondered why only too few people are successful? Many people work hard, they constantly chase for opportunities but still they have to spend and finish their careers with unsubstantial results. This is sad, so is the truth.
Like unsuccessful people, successful people chase for opportunities too, but what makes success scarce whereas mediocrity is abundant in professional careers?Join This Discussion >>
Hi there, I love that you're here because one of my favourite things to do is take a smart professional and lifetime student like yourself and make you become even more successful.
It's something that I practice in my own career, of course, but I love helping others too.Join This Discussion >>
Hi there, I hope I found you well and healthy. I am writing you about a subject that I was thinking since long time to write about it. Today is the day. :)
Are you looking for PDUs (Professional Development Units) to get or maintain a degree?
You shouldn't. Here is why? Because PDU is a byproduct of Lock-In Business Model, and this business model badly takes advantage of students.Join This Discussion >>
The role of a Scrum Master is one of many stances and diversity. A great Scrum Master is aware of them and knows when and how to apply them, depending on situation and context. Everything with the purpose of helping people understand and apply the Scrum framework better.Join This Discussion >>
You are moving from the world of fixed nouns towards a world of fluid verbs. Within the next years you will continue taking solid things -such as a car or a jacket- and turning them into intangible verbs. Your products are becoming your services and processes. With high doses of built-in technology, your car is becoming a service, continuously updated set of benefits adapting to your own usage and feedback, fierce competition and global innovation.Join This Discussion >>
The term ‘Meeting’ brings to our mind an atmosphere where a group of people are sitting together to discuss serious issues: Some sitting bored and uninterested; some staring blankly trying hard to get a grasp of what are being discussed; and still some aggressively trying to prove their point. However, with changing times and methodologies, with pressure to meet deadlines, with time constraints, with increasing competition and with the need to stay a step ahead, there arose a new face of meetings- ‘The Scrum Meetings’ or more commonly known as ‘The Daily Scrum Meetings’.Join This Discussion >>
There is so much more to be a software tester than merely logging bugs and testing to identify errors. There are inspiring examples of Agile working environments. Software testers have there the privilege to work as part of development teams which are like working on a movie set with the writers and producers. The testers work with everyone on the team, from the Junior Programmers to the Senior Project Leaders and inventors to continuously improve and build quality into the products and services.Join This Discussion >>
Are you good at business models?
Of course you are. We know all about business models, don’t we?
A lifetime as a consumer and almost a lifetime as a professional we all believe that we are well proficient in business models. We don’t hesitate more than a second to give our opinion if a business idea will work or not. And we are very generous to give our feedback how a company can perform better. But do we really have enough insights about business models?Join This Discussion >>
Our typical approach is to present organisational and moral benefits of Agile Scrum. How instantly Agility would enhance our teams and excel the interactions within our organisation and with our client ecosystem. How wonderfully our companies would serve customer-oriented products and services.
Is this really the correct approach? Is it better to highlight benefits of adopting Agile Scrum or the cost of not adopting?Join This Discussion >>
Dear Friends and Colleagues,
For the last few weeks we worked hard for you to make this revamp happen. If you are curious to know how International Scrum Institute uses Scrum, here are two simple facts for you which may be also a benchmark for your own agile delivery projects.Join This Discussion >>