Will you start a new project in a country which is badly affected by a pandemic?. Will you not check for the medical facilities available before investing?.
These days large project endeavors looks similar to enterprises and PM plays the CEO role within projects. Large projects are getting more and more complex and project failures will eat into the profitability of the enterprise, if not wiping out the enterprise. Understanding the project enterprise’s environmental factors upfront will help to factor them into Project plans.
Here are some examples;
Bank interest rates
Probability for extreme climatic conditions
Health care systems
Health and safety norms
These are just examples. A good understanding of the Enterprise Environmental Factors (EEF) will help to estimate, plan, execute, monitor, control and close projects successfully. EEF impacts almost every aspect of the project. An advance knowledge of EEF will help the project stakeholders steer the project successfully.
A well managed sprint planning meeting provides amble opportunities to discuss divergent views before converging on the best. This facilitates dialogue among the team members, which adds tremendous opportunity to learn from each other. This co-learning results in enhancement of the capability of the team. This in turn translates to better productivity.
This blog post examines the fundamental guidelines to sprint planning meeting effectivenessbased on my hands on experience as an agile coach. I will be updating this list further as when I gain more insights about conducting effective sprint planning meetings.
Last updated on 25/May/2020
Sprint planning meeting guidelines
Duration of the sprint planning meeting – For a thirty days sprint we need eight hours for effective sprint planning. If that is the case, how much will it take if the sprint duration is two weeks?. The most common answer is ‘4’ hours. Believe me, sprint planning will take a minimum of 5 hours even if the sprint duration is 5 days. That is one of the reasons why very short sprints are not very effective. Plan for 5 to 8 hours for sprint planning meetings.
Time boxing of the sprint planning meeting – As already discussed, the sprint planning meeting is time boxed into 5 – 8 hours depending on the sprint duration. The sprint planning meeting is further split into two logical halves of equal duration. The first segment is for selecting the sprint backlog from the product backlog. The second segment is for decomposing the sprint backlog further into the activities that need to be performed to build those features. and the second segment is for preparing the sprint back log.
The Participants of the sprint planning meeting – The attendees are the scrum master, the product owner / product manager and the development team comprising of professionals with the required skills to build the product. Additional parties can be invited to provide additional business domain or technology domain information and advice, but they are dismissed after this information is provided.
Product backlog readiness – Product backlog readiness is one of the key success factors for effective sprint planning. The product owner must prepare the product backlog to sufficient detail to enable the team to estimate the work. As a generally followed good practice, it will be useful if the product owner can prepare the user-stories at least for the features he/she is planning to schedule into the sprint.
Product manager availability – It is always advisable for the product manager to be present during the sprint planning meeting. In the absence of either the product owner or the product backlog, the scrum master is required to construct an adequate product backlog prior to the meeting and to stand in for the product owner, provided he has the capability and product vision.
Sprint backlog – The goal of the first segment, or first 4 hours of the sprint planning meeting is for the team to select those product backlog items that it believes it can commit to turning into an increment of potentially shippable product functionality. The team will demonstrate this functionality to the product owner and stake holders at the sprint review meeting at the end of the sprint.
The team can make suggestions, but the decision to what product backlog can constitute the sprint is the responsibility of the product owner.
The team is responsible for determining how much of the product backlog that the product owner wants worked on the team will attempt to do during the sprint.
Time boxing the first segment to 4 hours means that this is all of the time that is available for analyzing the product backlog. Further analysis must be performed during the sprint. Large-grained, high-priority product backlog with imprecise estimates might not be thoroughly understood during this part of the sprint planning meeting and might result in the team not being not able to complete all of the product backlog that it selects.
The second segment of the sprint planning meeting occurs immediately after the first segment and is also time boxed to 4 hours.
During the second half of the sprint planning meeting, the team;
Identifies the activities that need to be performed to construct the features agreed upon during the first half of the sprint planning meeting.
Estimate the effort required to complete these activities
Validates with the available capacity and productivity to ensure that the team can build what is committed.
The product owner must be available to the team during the second segment to answer questions that the team might have about the product backlog.
It is up to the team acting solely on its own and without any direction from outside the team to figure out during the second segment how it will turn the selected product backlog into an increment of potentially shippable product functionality. No one else is allowed to do anything but observe or answer questions seeking further information.
Sprint Planning Meeting Output – The output of the second segment of the sprint planning meeting is a list called sprint backlog, of tasks, task estimates and ‘volunteered work’ that will start the team on the work of developing the functionality. The task list might not be complete, but it must be complete enough to reflect mutual commitment on the part of all team members and to carry them through the first part of the sprint, while the team devises more tasks in the sprint backlog
Some of the key challenges of sprint planning meetings
Under the pretext of lack of time, some of the senior members does all the estimation work and thrusts that upon the rest of the team.
Lack of involvement of the team – Many team members do not participate well during the sprint planning meeting. At the same time I have seen many participating well as well. The root cause for lack of participation is lack of preparation. Still I remember the youngest engineer (had just 3 months work experience) who got introduced to me as ‘The most valuable engineer’ by the scrum master. He used to contact the product owner weeks before the sprint planning meeting to collect the probable features the product owner is planning for the next sprint. Then he starts R&D work on those features. By the time he enters the sprint planning meeting, he has a very good idea about the work that need to be performed to build those features. That is the right way to go.
Insufficient preparation by the product owner prior to the sprint planning meeting. Because of this, very often the product owner is unable answer the team’s queries regarding functionality. Even though the scrum guide does not say anything about this, based on my experience, it will be better if the product owner could prepare the user stories for the features she is planning for the sprint before getting into the sprint planning meeting.
Absence of the product owner during the sprint planning meeting. In this scenario, quite often the team will get struck during the sprint planning meeting due to lack of details.
Insufficient clarity about the reason behind doing a size based estimate (story points), before arriving at the effort. Unless one have in-depth understanding of the scrum framework and empiricism there will be ambiguity between size estimates and effort estimates. Why cant we jump into effort estimates directly?. I will soon write a blog post to explain this in detail.
Planning meeting with remote teams
Send the proposed sprint backlog in advance to the planning team so that they can prepare well before coming to the meeting.
Properly conducted daily scrum meetings or scrums is the most important, most recurring ceremony within the scrum framework which has the power to drive things forward. That realization drives me to update this page at regular intervals.
Last updated on 25/May/2020.
The daily scrum meeting is time boxed to 15 minutes regardless of the number of team members. This automatically restricts the team size to be less than 10, so that each person gets at least one and half minutes to update the status of his / her work to the rest of the team. Very long, daily scrum meetings is a waste of time in the eyes of the team members, and demotivates the team members in the longer run. Hence it becomes imperative to manage the daily scrum meetings (also known as daily scrums), according to the scrum meeting guidelines.
Fixed venue and time – Hold the daily scrum in the same place at the same time every work day. The daily scrum is best held first thing in the day so that the first thing team members do on arriving at work is think of what they did the day before and what they plan to do today.
Full attendance – All team members are required to attend. If for some reason a team member cannot attend in person, the absent member must either attend by phone or by having another team member report on the absent members status.
Promptness – Team members must be prompt. Remember, the only thing non-negotiable in scrum is ‘time’. So, be on time, to start the meeting on time. Making others wait for you is not a good indicator of ‘mutual respect’, which is one of the pillars of scrum framework. The the daily scrum starts at the appointed time regardless of who is present. There is no room for habitual late comers in scrum teams.
Circular Team formation – Scrum teams are self organizing, hence there is no room for command and control. In order to protect the teams from command and control freaks, the teams must stand in a circular formation, so that there is no boss – subordinate relationship. In a circular formation, there is no room for hierarchy.
Auto startermode – Once the circular team formation is done for the daily scrum meeting, someone in the formation should start the meeting without waiting for any command from the top (scum master / product owner). Once the meeting begins the meeting proceeds in a counter clockwise direction or on a clockwise direction from the starter of the meeting. Be consistent with any one of these patterns, so that unwanted repeated reminders and instructions can be avoided.
Focus – During the 1.5 minute individual window for each team member during the meeting, each team member should respond to the following three questions only:
What did I do yesterday regarding the project?
What am I intending to do between now and the next scrum meeting?
What are the challenges I am facing and need support?
Team members should not digress beyond answering these three questions into issues, designs, discussion of problems, or gossip. The scrum master is responsible for moving the reporting along briskly, from person to person.
During the daily scrum, only one person talks at a time. That person is the one who is reporting his / her status. Everone else listens. There is no side conversations.
When a team member reports something that is of interest to other team members or needs the assistance of other team members, any team meber can immediately arrange for all interested parties to get together after the daily scrum to set up a meeting.
Chickens (observers who are not part of development team) are not allowed to talk, make observations, make faces or otherwise make their presence in the daily scrum meeting obtrusive.
Chickens stand on the periphery of the team so as not to interfere with the meeting
If too many chickens attend the meeting, the scrum master can limit attendance so that the meeting can remain orderly and focused.
Chickens are not allowed to talk with team members after the meeting for clarification or to provide advice or instructions.
Those who cannot or will not conform to the above rules can be excluded from the meeting
How to conduct effective daily scrum meetings (stand up meetings) while working remotely?
The rule number one is to have a fixed start and end time for the daily scrum meetings, so that participants can plan their days work better.
If the bandwidth permits, have your cameras on, so that participants can see each other during the meeting.
In a co-located team, it was easy to decide who will speak when. In a virtual meeting the team will have to establish a norm for it.
Time management of a virtual meeting is critical. Scrum master and the team members must ensure this.
If the team is multicultural, there must be orientation on cultural aspects so that communication is effective.
Symptoms of dysfunctional scrum meetings (daily stand up meetings)
Here are the symptoms of dysfunctional daily scrum meetings one can observe without intervening with the team’s work;
Long stand up meetings which far exceeds the allocated time of 15 minutes
The scrum master / product owner standing on one side, and the rest of the team standing on the other side facing the scrum master / product owner.
Scrum master / Product owner asking questions and giving solutions to the team even when none asked for help.
Combining scrum meeting and the problem solving together
Some of the key team members on mobile or on other urgent work
Switching into sprint review mode
Half the team sitting down and half standing up during the meeting
Team members waiting for the scrum master to start the meeting
Discussions digress into non sprint related topics
Frequent meeting cancellations
Frequent rescheduling of meetings
Reference : ‘Agile project management with SCRUM’ by Ken Schwaber
During the last two decades Agile Project Management (APM) has matured in the Information technology projects. Now the time has come for other project disciplines to embrace the agile best practices to work efficiently remotely, which has become the norm of the day. Below are the benefits reported by the early adopters of agile in EPC projects;
Increased communication between members of the project team, as well as between the project team and relevant stakeholders.
The visibility and ability to follow what the team is doing is at a whole other level
The transparency to others outside the team is close to perfect
People only work on tasks that are on the task list, and these are in a prioritized order
When stakeholders see what tasks are on the task list and what priority their task has in relation to other tasks, they become more patient with waiting for their task to be finished
Builds better relations between the team and their internal customers
With the opportunity to bring forth problems in daily meetings, the transparency has increased a lot
Problems surface quite quickly, allowing them to be solved faster
The problems are often identified by the team
When a problem is brought to the team’s knowledge during the daily meetings, others can immediately help with the problem
If a change is in conflict with another change it can be spotted as soon as possible
If a problem then surfaces it is easy to find , since only one day’s work has to be gone through to find the problem and people still remember well what they have done during the day
A project can last for 1.5 years and previously feedback wasn’t gathered into a final report until the end of the project. This feedback could then be utilized to improve future projects. Today thanks to Scrum this cycle is much faster and they ask for and discuss feedback continuously
Process improvement activities have become part of the project
Unified the ways of working
Business development efforts are also accounted
Quick introduction to Agile Project Management (APM)
Agile is a family of frameworks like;
Test Driven Development (TDD)
Of these ‘Scrum’ and ‘Kan-ban’ are the most popular ones and are domain independent, hence adoption to EPC projects is easier.
At the center of all agile frameworks is the iteration, which is a time box, with a maximum duration of 30 days. The team can decide on the duration of the iteration with the only stipulation that iteration duration cannot be more than 30 days. At the beginning of every iteration the multi-disciplinary team decides the work they will perform during the iteration, and then they go ahead and perform the work. Every day, the team conducts a ‘daily stand up’ meeting with a maximum duration of 20 minutes, where each team member get approximately 2 minutes to communicate three things (What did I do yesterday?, What am I doing today?, and what are the issues I am facing and need help to resolve). At the end of the iteration there is a formal review of the output of the iteration followed by a retrospective meeting to capture the lessons learned during the iteration.
Let us take a detailed view of the scrum framework.
Overview of Scrum framework
The Scrum framework was established by Ken Schwaber and Jeff Sutherland in the year 1993. This is a very simple framework based on the scrum values of;
Product backlog (task list)
Is the pending task list towards a major milestone. When the product backlog gets exhausted, that is an indication that the associated milestone is about to get accomplished.
Sprint (Iteration) backlog
The scrum project progresses in sprints (iterations). Sprint is a time box not exceeding 30 days. Before the start of the sprint, the team sits together and decides what all things they can commit during the next sprint (time box). Once they agree on a set of tasks to be completed during the sprint, they prepare detailed plan for the sprint. The output of the sprint planning meeting is the sprint backlog which comprises of tasks and responsibilities.
During the sprint, the team carryout the work related to the sprint.
Daily stand-up meeting
Daily stand up meetings are 20 minute meetings (for 10 member teams) where each person explains three things to the rest of the team like;
What did I do yesterday?
What am I doing today?
What are the issues I am facing and need help?
This helps the team to see the status of the sprint on a daily basis. This also increases collaboration among team members to resolve issues quickly.
On the last day of the sprint, the team along with other key stakeholders review the status of the output of the sprint. If all the planned activities are completed with the required quality, the sprint is considered as successful.
After the Sprint review, sprint retrospectives are conducted. The lessons learned during the sprint are consolidated and incorporated into the subsequent sprint’s planning meeting.
Is tracking board where tasks are classified into ‘To be done’, ‘Being done’ and ‘Done’. Based on the progress made the tasks are moved across these columns. The sprint board provides absolute clarity about who is working on which task and the status of every task to the project’s stakeholders.
Burn down charts
The ‘X’ axis of the burn down chart always represent the duration of the iteration (sprint). The ‘Y’ axis represents either the number of tasks to be completed, or the equivalent cumulative value (size, effort) of the tasks to be completed. The cumulative value on the ‘Y’ axis is updated on a daily basis based on the actual progress made.
Kanban is a sprint without start date and end date. That represents continuous flow with thresholds defined for every stage of the work. This works based on a pull system based on ‘Stop starting things, Start finishing things’.
As you can see scrum is simple to understand. All the ceremonies of scrum together creates the necessary peer pressure, discipline, transparency resulting in optimal productivity of the remote teams.
Opportunities to apply agile best practices within EPC projects
Rules of credit are used to measure the progress of work completed against the planned work. The most commonly used rules of credit are;
0/100 – Work is considered as earned (completed) when it is 100% completed.
50/50 – 50% of the work is considered as earned as soon as the work starts. The remaining 50% will be considered as earned only when the remaining 50% is fully completed.
25/75 – 25% of the work is considered as earned as soon as the work starts. The remaining 75% is considered as completed only when 100% of the work is completed.
20/80 – 20% of the work is considered as earned as soon as the work starts. The remaining 80% is considered as completed only when 100% of the work is completed.
When none is defined, we apply % completed based on actual measurement or expert judgment.
Rules of Credit – Examples
Let us see how the progress is reported based on the various rules of credits discussed above. The orange arrow indicates the review point.
Defining rules of credit at the activity level during project planning is key to progress monitoring and control. The commonly used rules of credit are 0/100, 50/50, 25/75, 20/80 and percentage completion based on actual progress made.