The Importance of Planning in an Agile Environment

planning in agile projects — Photo by Startup Stock Photos on Pexels.com

In today’s fast-paced business world, it can be tempting to skip the planning process altogether, especially in an Agile environment where change is constant and the future is unpredictable. However, planning is still an essential part of any successful project. It provides a baseline for future discussions, allows for stakeholder input, and helps balance the portfolio of projects.

When creating a roadmap, the team should understand that change is not only possible, but necessary. Any new change should make the plan better, whether that means adding higher priority items, dropping lower ones out, making the plan more achievable or less risky, or better aligning schedules and dependencies. The original plan sets a baseline for future evaluations and discussions. Without a starting point, it’s impossible to know if a suggested change is a good one or not. Having a baseline plan makes it easier to make value comparisons and have healthy discussions.

Another use of a baseline plan is as a communication vehicle to talk about the roadmap with stakeholders. It allows stakeholders to ask their questions at the beginning and see if they can exert influence while there is still time to do so. Being able to start a conversation by recognizing the plan is only a draft invites input and changes at a time when changes are less expensive than later in the process. Using the baseline as a mechanism to have these discussions will be a lot easier than going to each stakeholder group with a blank canvas and attempting to fill it in with each one.

Part of the job of a program or portfolio manager is to create a balanced plan; a portfolio of projects that supports the organizational strategy. To see if a plan has balance, looking at the whole plan is required. Even if each project is solid on its own, it may not be true for the entire collection of projects. Creating a baseline portfolio allows for changes based on the entire plan, not just a single project.

For instance, assume that a portfolio contains ten projects. While all ten of them may anticipate good ROI, or all seem to have solid business cases behind them, it could very well be that isn’t true for the entire collection of projects. For example, while each of the projects are good, few of them have the chance to be spectacular, and none of them have the chance of truly outsized results. This may cause a program manager to make a change to the portfolio, adding in a more speculative and riskier project, and taking out one that has a higher chance of succeeding, but a lower ceiling if it does. On a one-for-one basis, this tradeoff might not make sense, but using a portfolio view, it can be wise. Remember that the goal doesn’t hinge on the outcome of one project, but instead on the collection of all of them.

Planning is still an essential part of any successful project or program, even in an Agile environment. It provides a baseline for future discussions, allows for stakeholder input, and helps balance the portfolio of projects. Skipping the planning process can lead to directionless execution or an inability to correct course mid-stream. Having a plan in place, even a flexible one, is essential for success in today’s business world.

Cost of An Agile Project

Calculating the cost of a sprint can be a complex task. However, by considering the following factors, we can get a better understanding of how much it will cost to complete a project:

Team size: The number of people working on the sprint will affect the cost. More team members mean higher cost. This is because each team member will require expenditure, and more people working on a project means more expenditure.
Team member rates: Each team member has a different hourly rate, depending on their role and experience level. For instance, a senior developer with years of experience will likely have a higher hourly rate than a junior developer. Therefore, it is important to account for these differences when calculating the cost of a sprint.
Duration of the sprint: The longer the sprint, the higher the cost. This is because more hours will be required to complete the project. Additionally, there may be additional costs associated with a longer sprint, such as increased overhead costs.
Overhead costs: These include expenses such as equipment, software licenses, office space, and utilities. These costs can add up quickly, especially for larger projects. Therefore, it is important to account for these costs when calculating the overall cost of a sprint.

Once we have all of the above information, we can calculate the cost of the sprint by multiplying the total number of hours worked by the team by the hourly rate of each team member. We then add any overhead costs to get the total cost of the sprint.

It is important to keep track of these costs and adjust them, if necessary, to ensure that the project stays within budget. By regularly monitoring the cost of a sprint, we can make informed decisions about how to allocate resources and keep the project on track.

In Scrum, the story point values are typically used to estimate the relative effort required to complete a task, rather than the actual cost in dollars or other currency. However, if the team has a good understanding of the relationship between story points and cost, they may be able to use story points as a proxy for cost when planning and budgeting for a project. This can be especially useful when working on an agile project where requirements are likely to change frequently, as it allows the team to adjust their budget and resources more easily as the project progresses.

How Can We Calculate Project Cost?

In an Agile project, it can be difficult to calculate the cost of a story point directly. However, by tracking the team’s velocity (i.e., the number of story points completed per sprint), we can estimate the team’s average rate of progress.

To calculate the cost of a story point, we need to know the average cost of a sprint. We can estimate this cost by dividing the total cost of a sprint by the number of story points completed in that sprint.

For example, if a sprint costs $10,000 and the team completes 50 story points, the cost per story point is $200 ($10,000 / 50).

Once we have an estimate of the cost per story point, we can use this information to plan and budget for future sprints. By estimating the number of story points required for each feature or user story, we can calculate the approximate cost of implementing that feature or story.

It’s important to note that this method is an estimate, and the actual cost of a story point may vary depending on a variety of factors such as team size, team member rates, and overhead costs. However, by tracking velocity and using historical data to estimate costs, we can make more informed decisions about how to allocate resources and plan for future sprints.

Critical Path is not Dead

In project management, the critical path is the longest sequence of tasks that must be completed on time to ensure that the project is finished within the scheduled time frame. The critical path method (CPM) is a project management technique that helps identify the most critical tasks in a project and determines the shortest possible time to complete it. The CPM has been around for more than half a century and is still one of the most popular project management techniques today.

Despite the emergence of alternative approaches, such as agile and lean methodologies, critical path analysis remains a fundamental tool for managing complex projects. Some people argue that the critical path method is outdated and no longer relevant in today’s fast-paced business environment. They argue that it is too rigid and inflexible, and that it does not allow for changes or adjustments to be made during the project. However, this is a misconception.

The critical path method is not rigid or inflexible. It is a tool that can be adapted to fit any project, regardless of its complexity or size. When used correctly, the CPM provides a clear understanding of the interdependencies between tasks in a project. It helps identify potential bottlenecks and areas where resources may need to be allocated differently. This level of insight is essential for managing complex projects and ensuring that they are completed on time and within budget.

Moreover, the critical path method is not limited to large-scale projects. It can be used in any project, regardless of size. Even small projects with a limited number of tasks can benefit from the CPM. By identifying the critical path, project managers can determine the most important tasks and allocate resources accordingly.

The critical path method is also valuable for risk management. By identifying the critical path, project managers can determine the tasks that are most critical to the project’s success. They can then focus their attention on these tasks and ensure that they are completed on time. This approach minimizes the risk of delays and ensures that the project is completed within the scheduled time frame.

In conclusion, the critical path method is not dead. It is alive and well in our projects. It remains an essential tool for project managers who want to ensure that their projects are completed on time and within budget. While alternative approaches may have emerged in recent years, the critical path method is still the most effective way to manage complex projects. Its adaptability, flexibility, and focus on risk management make it an invaluable tool for any project manager.

Servant Leader

A servant leader is a person who serves the team members and helps them to achieve their goals. In Scrum approach, a servant leader plays a crucial role in facilitating the Scrum process and ensuring that the team is functioning effectively.

The servant leader serves the team in several ways in Scrum. Firstly, the servant leader helps the team to understand the Scrum framework and provides guidance on how to implement it effectively. This involves educating the team members on the principles and values of Scrum, and how they can apply them to their work. They work closely with the Scrum Master to ensure that the team is following the Scrum process and that any issues are resolved quickly. The servant leader also helps the team to define their goals and objectives, and how they can align them with the project’s vision.

Secondly, the servant leader fosters a collaborative environment where team members can work together effectively. They encourage open communication, trust, and respect among team members. The servant leader also helps to identify and remove any obstacles that may be hindering the team’s progress. They facilitate meetings and discussions to ensure that everyone’s ideas and opinions are heard and considered. By creating an environment where team members feel safe to share their thoughts, the servant leader can unlock the team’s full potential.

Thirdly, the servant leader supports the team by providing them with the necessary resources and tools to complete their work. They ensure that the team has access to the right technology, training, and support to deliver high-quality work. The servant leader also helps the team to manage their workload and balance their priorities. They provide feedback and coaching to team members to help them improve their skills and become more productive.

In conclusion, a servant leader serves the team in Scrum by providing guidance, fostering a collaborative environment, and supporting the team with the necessary resources and tools. By doing so, they help the team to work together effectively and achieve their goals. The servant leader is a crucial member of the Scrum team, and their role is essential for the success of the project.

Does a Servant Leader help Personal Lives

A servant leader’s primary responsibility is to serve the team by facilitating the Scrum process and ensuring that the team is functioning effectively. Although a servant leader may be supportive of team members’ personal lives, their primary focus is on the project and the team’s work.

That being said, a servant leader may still be able to support team members outside of their project work, depending on the specific circumstances. For instance, suppose there are two young people on the Scrum team who need to find a house to live in after their wedding. In this case, it may not be expected for the servant leader to directly assist them in their house renting process.

However, the servant leader can still support team members by helping them manage their workload effectively. By doing so, team members can have more time to search for a house outside of work hours. The servant leader can also suggest ways for team members to prioritize their tasks so that they can balance their personal and professional lives more effectively.

Furthermore, if team members’ personal situations are affecting their work, the servant leader can work with the Scrum Master to find a solution that benefits both the team and the project. For example, the servant leader can suggest a temporary adjustment to the team’s work schedule so that team members have more time to search for a house. Alternatively, the servant leader can help team members delegate some of their work to other team members so that they can focus on finding a house.

What does a servant leader do in a day?

A servant leader’s day-to-day activities are highly dependent on the needs of the team and the project. One of their key responsibilities is to meet with team members individually to provide guidance and support. This includes listening to their concerns, answering their questions, and providing them with the resources they need to succeed. Additionally, a servant leader will often facilitate meetings and discussions among team members to ensure that everyone is on the same page and that progress is being made.

Furthermore, a servant leader will help to remove any obstacles that may be hindering the team’s progress. This could involve identifying a lack of resources, clarifying ambiguous requirements, or resolving conflicts between team members. They will also work closely with the Scrum Master to ensure that the team is following the Scrum process and that any issues are resolved quickly.

Another key aspect of a servant leader’s role is providing feedback and coaching to team members. This includes providing constructive criticism and helping team members identify areas for improvement. They will also work with team members to develop skills and competencies that will help them become more productive and effective. Ultimately, a servant leader’s goal is to serve the team by helping them to achieve their goals and work together effectively, while also fostering an environment of continuous learning and improvement.

Poor Performance of a Team Member

When a team member is not performing well, it can have a significant negative impact on the overall performance of the team. In Scrum, it is essential to address poor performance as soon as possible to ensure that the team can meet its goals and deliver value to the customer.

Managing the poor performance of a team member in Scrum involves a series of steps that are designed to help the team member improve their performance while ensuring that the team can continue to meet its objectives. Here are the steps that can be taken to manage poor performance of a team member in Scrum:

Identify the problem: The first step is to identify the problem. This can be done by analyzing the team’s performance data, observing the team member’s behavior, and getting feedback from other team members. It is essential to understand the root cause of the poor performance to determine the most effective way to address it.
Communicate with the team member: Once the problem has been identified, it is important to communicate with the team member. This can be done through a one-on-one meeting or a team meeting. During the meeting, it is important to clearly explain the concerns about their performance and its impact on the team’s overall performance. It is also essential to listen to the team member’s perspective and understand their challenges, concerns, and feedback.
Set expectations: During the meeting, it is important to set clear expectations for the team member. This includes outlining what is expected of them in terms of their role, responsibilities, and performance. The expectations should be specific, measurable, achievable, relevant, and time-bound (SMART).
Provide support: It is important to provide support to the team member to help them improve their performance. This can include providing training, coaching, or mentoring. The support should be tailored to the team member’s specific needs and should be designed to help them address the root cause of their poor performance.
Monitor progress: After setting expectations and providing support, it is important to monitor the team member’s progress. This can be done through regular check-ins, performance reviews, and feedback from other team members. The monitoring should be ongoing and should be designed to help the team member stay on track and make progress towards meeting the expectations that have been set.
Take action if necessary: If the team member’s performance does not improve despite the support provided, it may be necessary to take further action. This can include reassigning tasks, providing more training, or, in extreme cases, removing the team member from the team. It is important to take action in a timely and respectful manner, and to communicate clearly with the team member about the reasons for the action and the implications for the team.

By following these steps, the poor performance of a team member can be effectively managed in Scrum, ensuring that the team can meet its goals and deliver value to the customer. Managing poor performance is an ongoing process, and it requires a continuous focus on improvement and a commitment to helping team members reach their full potential.

Burn-down vs. Burn-up Charts

Agile methodology is a popular approach used in software development, which involves iterative and incremental development. It emphasizes on delivering the highest business value in the shortest amount of time.

Two popular charts used in agile methodology are Burn-Down and Burn-Up charts. These charts are essential tools that help teams visualize the progress of their work across iterations or sprints.

Burn-Down charts track the amount of work that remains to be done versus the time remaining. The chart shows a downward trendline, which represents the amount of work remaining. This chart is useful in identifying the team’s progress and helps the team to stay on track with their goals. It also helps the team to identify any potential issues that may arise during the project.

On the other hand, Burn-Up charts track the amount of work that has been completed versus the time remaining. The chart shows an upward trendline, which represents the amount of work completed. This chart is useful in showing the team’s progress and helps to identify whether they are on track to meet their goals. It also helps to demonstrate to stakeholders how much progress has been made and how much work remains.

In summary, the main differences between Burn-Down and Burn-Up charts are the direction of the trend lines. Burn-Down charts show the amount of work remaining, while Burn-Up charts show the amount of work completed. Both charts are useful in tracking progress and providing visibility to the team and stakeholders.

Overall, the use of these charts is an important aspect of agile methodology, as they provide teams with a way to track their progress, identify potential issues, and communicate effectively with stakeholders. By using these charts, teams can stay on track with their goals and ensure that they are delivering the highest business value in the shortest amount of time.

Kano Model

The Kano model is a theory of product development and customer satisfaction. It was developed by Japanese researcher Noriaki Kano in the 1980s. The model helps businesses understand and prioritize which features of their product or service will most effectively satisfy and delight customers.

The Kano model categorizes product features into three groups:

Must-have or basic features
Performance features
Delight features

The must-have features are the basic features that customers expect a product or service to have to meet their minimum requirements. If these basic features are not present, customers will be dissatisfied. For example, a smartphone must have a functioning touchscreen and the ability to make phone calls.

Performance features are features that are important to customers and can increase customer satisfaction, but their absence won’t necessarily lead to dissatisfaction. For example, a smartphone that has a long battery life or a high-quality camera.

Delight features are unexpected features that can create a positive emotional response from customers. These features can set a product or service apart from competitors and can create loyal customers. For example, a smartphone that has a built-in projector or has a unique design.

In summary, the Kano model helps businesses to understand what features of their product or service are most important to customers and how to prioritize their development efforts. By focusing on delight features, businesses can create a unique selling point and increase customer loyalty.

Product Owner’s Expertise

Dr. Jason Dworkin, Project Scientist by NASA Goddard Photo and Video is licensed under CC-BY 2.0

A product owner plays a critical role in ensuring that a project meets the needs of the customers and stakeholders. They are responsible for translating the customer’s needs into actionable tasks for the development team. In addition to this, the product owner must also ensure that the project stays within budget and meets the deadline.

While some may wonder whether having expertise in the subject matter of the project is necessary for the product owner, the answer is no. In fact, having someone too close to the subject matter can hinder the project’s progress. This is because they may get too invested in the details and lose sight of the bigger picture. However, it is still important for the product owner to have a basic understanding of the subject matter to communicate effectively with the team members and stakeholders.

On the other hand, a product owner who maintains a high-level view of the project can ensure that it meets the needs of the stakeholders. They also have the necessary communication skills to interact effectively with the team members and stakeholders. This includes the ability to listen actively, ask questions, and provide constructive feedback.

It is essential for the product owner to prioritize requirements effectively, which means they must have a deep understanding of the product vision. They should be able to identify the most critical requirements, allocate resources accordingly, and set achievable goals. In addition to this, the product owner should also be able to identify potential risks and develop contingency plans to mitigate them.

In conclusion, while subject matter expertise can come in handy, having a product owner who is too close to the subject matter can be a hindrance. Instead, a product owner should have strong communication skills, be able to prioritize effectively, and maintain a high-level view of the project. This will ensure that the project meets the needs of the customers and stakeholders and stays within budget and timeline.

Lead Time vs. Cycle Time

Lead Time on Agile Approach

Lead time in Agile approach is the duration between the initiation of a project and the delivery of the final product. In the Agile methodology, the focus is on delivering a high-quality product in the shortest possible time. Therefore, reducing the lead time is a crucial aspect of Agile development.

The lead time can vary depending on the complexity of the project, the size of the team, and the availability of resources. However, in general, Agile teams aim to deliver the product in small increments, with each increment adding value to the final product.

To reduce lead time, Agile teams follow several practices, including continuous integration and delivery, test-driven development, and frequent collaboration with stakeholders. These practices help identify and resolve issues early in the development process, ensuring that the final product meets the customer’s requirements.

In conclusion, lead time is a critical factor in Agile development, and Agile teams strive to reduce it by delivering the product in small increments, following best practices, and collaborating with stakeholders.

Cycle Time on Agile Approach

Cycle time in Agile approach is the duration between the start and completion of a single task or user story. It is the time taken to deliver value to the customer. Agile teams aim to reduce cycle time by breaking down tasks into smaller, more manageable pieces and delivering them incrementally. By doing so, they can identify and address issues early in the development process, ensuring that the final product meets the customer’s requirements.

Product Backlog vs. Work Breakdown Structure

Product Backlog and Work Breakdown Structure (WBS) are two important planning tools used in project management. Although they are similar in some ways, they differ in their scope, purpose, and level of detail.

Product Backlog

A Product Backlog is a prioritized list of features or requirements that a team plans to deliver in a project. It is a dynamic document that is updated continuously throughout the project lifecycle. The Product Backlog is owned by the Product Owner, who is responsible for prioritizing the items based on their value to the customer.

The Product Backlog helps the team to understand and plan what they need to deliver. It is a high-level view of the project that provides a big picture of what the product will look like. The items in the Product Backlog are not broken down into smaller tasks.

Work Breakdown Structure (WBS)

A Work Breakdown Structure (WBS) is a hierarchical decomposition of the project deliverables into smaller, manageable components. The WBS breaks down the project into smaller, more manageable pieces that can be estimated and scheduled. Each component of the WBS is called a Work Package.

The WBS is a detailed view of the project and is used to plan and manage the project execution. It is owned by the Project Manager, who is responsible for ensuring that the project is completed on time, within budget, and meets the quality standards. The WBS includes all the tasks required to complete the project and is used to track progress and identify potential issues.

Differences

The main differences between Product Backlog and Work Breakdown Structure are:

Scope: Product Backlog focuses on the high-level view of the project, while WBS focuses on the detailed view of the project.
Purpose: Product Backlog is used to prioritize the features or requirements to be delivered, while WBS is used to plan and manage the project execution.
Level of Detail: Product Backlog does not break down the items into smaller tasks, while WBS breaks down the project into smaller, manageable components.

In conclusion, both Product Backlog and Work Breakdown Structure are important planning tools that are used in project management. While they have some similarities, they differ in their scope, purpose, and level of detail. Understanding these differences is crucial for effective project planning and execution.

Scrum for Project Managers E-Book (PDF) 1.0

Are you tired of managing projects that seem to drag on forever? Do you feel like you’re constantly putting out fires instead of making real progress? It’s time to try a new approach.

Introducing Scrum for Project Managers, the e-book that will revolutionize the way you approach project management. Our comprehensive guide will teach you everything you need to know about Scrum, an agile project management framework that has been proven to increase productivity, improve communication, and deliver results.

In this e-book, you’ll learn the basics of Scrum, including how to create and manage a product backlog, how to conduct sprint planning and review meetings, and how to effectively communicate with your team. You’ll also discover advanced techniques for improving team collaboration, managing stakeholder expectations, and delivering high-quality products on time and within budget.

Whether you’re a seasoned project manager or just starting out, Scrum for Project Managers is the must-have resource for anyone looking to improve their project management skills. And with our easy-to-read format and practical advice, you’ll be able to start implementing Scrum in your projects right away.

Chapter 1- Scrum Approach

The Agile Manifesto and the Birth of Scrum. 10
Overview of Scrum Framework 12
Scrum Artifacts 14
Organizational Goals in Scrum 16
What is the Backlog? 19

Chapter 2 – Product Backlog

Product Backlog in Scrum 23
An Example of Scrum Practice 25
User Stories 27
Refining and Estimating Product Backlog 30

Chapter 3 – Sprint Backlog

Sprint Backlog 35
Sprint Scope and Sprint Goal 37

Chapter 4 – Definition of Done

Increment and Definition of Done 42
More Details of “Definition of Done” 45
When should the DoD be Prepared? 48
Definition of Done vs. Acceptance Criteria 50

Chapter 5- Scrum Events

What are Scrum Events? 53
What is a Time Box? 55
More Details About The Sprint 57
Sprint Planning Event 59
Why is the Sprint Valuable? 61
What can be Done in the Sprint? 63
How will Things Be Done in the Sprint? 66
Who Attends the Sprint Planning Meeting? 68
Coherency of Sprint Backlog Items 70
Daily Scrum 72
Sprint Review Meeting 74
Sprint Retrospective Meeting 76
Understanding Epics 80
Special Sprints 83
Canceling a Sprint 85

Chapter 6 – The Scrum Team

Scrum Team 88
Scrum Team Size 90
Product Owner 92
What is Value 94
How is the Product Backlog Ordered? 96
The Developers 98
The Scrum Master 100
How does the Scrum Master serve to the Scrum Team 102
What is an Impediment in Scrum? 104
How does the Scrum Master serve to the Product Owner? 106
How does the Scrum Master serve to the Organization 108
Other Titles in Scrum 110

Chapter 7 – Scaling Scrum

Introduction To Scaling Scrum 115
What happens when multiple Scrum Teams work on the same Product? 117
Impact on velocity when scaling Scrum 118
Integrated Product Increments 120
The Definition of Done when multiple teams work on the same Product 122
Must the Sprints be aligned? (same length, same start/end) 124
How many Product Owners are there? 126
Feature teams vs Component teams 128
The importance of creating an integrated Increment 130

Chapter 8 – Terms and Tools Used in Scrum

The Velocity of the Scrum Team 134
Technical debt 136
Functional and non-functional requirements 138
The process of emergence in Scrum 140
Burn-down charts 142
Burn-up charts 144
The “cone of uncertainty” 146

Chapter 9 – Agile Framework and Practices

Agile Framework Overview 150
Kanban 152
Extreme Programming (XP) 155
Test-driven development (TDD) 157
Behavior-driven development (BDD) 159
DevOps 161

Chapter 10 – FAQ about Scrum

Is Documentation Mandatory in Scrum? 165
What happens with incomplete Sprint Backlog items? 167
Who creates the Definition of Done? 168
How to change scope without affecting the Sprint Goal? 170
What happens if there is no Increment and/or the Sprint Goal is not reached? 171
The difference between Product Backlog Refinement and Sprint Planning 173
What is the difference between creating an Increment and Releasing it? 175

About The Author

Gökrem Tekir graduated from Anadolu University in 1997 as an Industrial Engineer.

He worked as a project engineer in different companies in the production and service sector. He earned the PMP Certificate in 2004.

After receiving the PMP Certificate, he continued his career as a Project Management Trainer and Consultant.

Among the trainings he gave, there are topics such as Fundamentals of Project Management, Agile Project Management, Scrum Approach, Project Planning and Follow-up with Microsoft Project, PMP Exam Preparation.

The consultancy services offered by Gökrem Tekir are the Establishment and Integration of Project Management Offices, Microsoft Project Server and Sharepoint Integration, Development of Enterprise-Specific Project Management Methods, Planning and Reporting of Projects Between Buyer and Sellers, Creation and Follow-up of Project Plans of Institutions, Projects of Employees. It is listed as Adapting to Management Methods.

Gökrem Tekir is the author of the first Turkish-language Project Management book in 2006. In 2017, a much more comprehensive work titled “Our Life is the Project – Project Manager’s Handbook” was also published.

Gökrem Tekir continues to share information on social networks such as Youtube, Linkedin, Twitter and Instagram in order to spread his knowledge on project management.

https://buy.stripe.com/6oE4jv5Fo8K7fNC5kx