Planning

Introduction

The importance of a dedicated planning phase in a group project cannot be understated. Planning is our opportunity to share ideas, set goals and place limitations on the project. When working on solo projects you may be able to build with an ad-hoc approach, but this quickly becomes impractical then impossible as the size of a team grows.

The act of planning itself is more important than the resulting planning documentation. By planning properly, we imagine the future of the project, anticipating issues, risks and opportunities. This is what gives us a feeling of being prepared, and without this step it is easy to become overwhelmed. Well planned projects are more likely to succeed.

Why we plan

In a work setting, the main advantage to planning is that it allows for maximum resource efficiency. In this context, we are the resource and our efficiency relies on delivering the agreed product on time. A well organised team of 10 developers can achieve in a week what a disorganised team of 100 developers could not in a month, or a single developer in a year. For a business, this means more turnover, faster outcomes and more shareholder profit.

From the perspective of the developer, a plan should make us feel comfortable and confident in our ability to deliver the project. At any moment, we should be able to consult our planning documentation and know quickly whether we are on track, ahead or behind. Without the overall roadmap, an unplanned development cycle can result in wasted time, duplicated effort and missed deadlines.

When working in a team, a plan helps to mitigate risks such as miscommunication, illness or unexpected events. A plan also helps to keep the team focused on the agreed goals, and provides a framework for making decisions. When a team is working towards a common goal, it is easier to make decisions that benefit the team as a whole. For example, a new feature idea may sound exciting, but if this delays or degrades the original plan then the team may decide to postpone it. Without this framework, a project can veer off course or lose momentum.

Let’s imagine a social media startup. The founders of Blabba have a concept for a voice-only social media platform. Using detailed prototypes and a limited tech demo, they have secured a round of funding from a venture capital firm. With this funding they have a large enough budget to hire a team of developers for a year. Whether they are able to secure further funding after this time will depend on whether they reach a target number of users. In this situation, the founders have a clear goal and a limited amount of time and money to achieve it. They need to plan carefully to ensure that they are able to deliver the product on time and within budget.

Allowing each developer free reign to work on whatever they want at a given time would be very difficult to manage, keep track of, or even measure. Instead, this project should be meticulously planned with input from the whole team before any work can begin.

Scope

The scope of a project is the amount of work that needs to be done to deliver the project. This includes all of the features, functionality and content that the founders have requested. The scope of a project is often the first thing to change during a project, and is the most common cause of missed deadlines or project failure.

Going back to the social media example, the founders have communicated requirements for user authentication, a feed of posts, a profile page, a search function and a messaging system. The founders have requested that the app be available on web and all mobile devices, and that it be compatible with all modern browsers. The founders have not specified a particular technology stack but have provided detailed wireframes and designs for the user interface. The founders have also mentioned that they would like to be able to add new features in the future, and that the app should be easy to maintain.

The scope of work is documented in a Project Specification document, which is shared with the founders for approval. The founders are happy with the scope of work, and the team begin to estimate the project tasks.

User Stories

A user story is a short description of a feature or functionality from the perspective of the user. User stories are used to define the scope of work, and are often written in the form of a sentence:

• As a user, I want to be able to register an account so that I can access the app.
• As a user, I want to be able to log in to the app so that I can access my account.
• As a user, I want to be able to search for other users so that I can find my friends.
• As a user, I want to be able to send a message to another user so that I can chat with them.
• As a user, I want to be able to post a message so that I can share my thoughts with others.
• As a user, I want to be able to view my profile so that I can see my posts and messages.
• As a user, I want to be able to view another user’s profile so that I can see their posts and messages.
• As a user, I want to be able to view a feed of posts so that I can see what others are saying.

This way of presenting requirements may be unfamiliar or difficult to approach at first, but it is a very effective way of communicating requirements. By writing requirements in this way, we are forced to place ourselves in the shoes of our non-technical users. The exact combination of technologies used to achieve a given feature is of no interest to an end-user, who simply requires the feature to work consistently.

This also helps to set expectations for the client, who may not be familiar with the technical aspects of the project. By writing requirements in this way, we are able to communicate the scope of work in a way that is easy to understand and agree upon.

Not all user stories are written from the perspective of an outside user. For example, a user story may be written from the perspective of an admin user:

• As an admin, I want to be able to delete a user so that I can remove inappropriate content.
• As an admin, I want to be able to ban a user so that I can prevent them from using the app.
• As an admin, I want to be able to view a list of all users so that I can monitor activity.
• As an admin, I want to be able to view a list of all posts so that I can monitor activity.
• As an admin, I want to be able to view a list of all messages so that I can monitor activity.
• As an admin, I want to be able to view a list of all reported posts so that I can remove inappropriate content.
• As an admin, I want to be able to view a list of all reported messages so that I can remove inappropriate content.

Failing to account for additional roles or personas within the world of an application can lead to missed requirements or a project over-run. For example, if the team had not considered the need for an admin user, they may have failed to include the ability to delete or ban users. This could have resulted in a delay to the project, or a loss of trust from the founders. In some cases, this may mean that the project cannot be certified under international data privacy laws.

Epics

During the planning process, there is a tendency to pair one story with one feature and assign this to a single developer. This is neither an accurate model of the project, nor an efficient way to organise a team. Instead, user stories should be grouped into Epics and assigned to a team of developers. This allows the team to work together to achieve a common goal, and to share knowledge and resources. There is a predefined order in which the epics should be completed, and each epic should be completed before the next can begin. Using the user stories from the previous section, we can group them into the following epics:

• Authentication
• Profile
• Feed
• Search
• Messaging
• Admin

By grouping the user stories into epics, we are able to see the bigger picture and plan the project more effectively. For example, the team may decide to work on the Authentication epic first, as this is a prerequisite for all other epics. Then the Profile epic, as this is a prerequisite for the Feed and Messaging epics. Next, the Feed and Messaging epics in parallel, as these are not dependent on each other. Finally, the Search and Admin epics in parallel, as these are not dependent on each other.

Now, when it comes to tackling the code required to complete a given user story, we have the benefit of being able to see it in context. This allows us to write less code, to achieve more in less time, with less to test. For example, much of the code needed to login is shared by the registration process. These two features can be approached in parallel, and the code can be shared between them. This is known as code reuse, and is a key principle of software development.

Tasks

Although epics and user stories provide a useful perspective on the project, neither of these are actionable. In order to fulfil a user story or epic, we must break it down into smaller tasks. Tasks are actionable statements that can be assigned to one or more developer. Let’s consider the register user story from the previous section:

• As a user, I want to be able to register an account so that I can access the app.

This could be broken down into the following tasks:

• Create an authentication service
• Create a registration form
• Create a registration endpoint
• Create a registration test

When a developer is assigned to a task, it should be clear what is expected of them. For example, if a developer is assigned to the Create a registration form task, they should know what the form should look like, and what fields it should contain. A blank task with no description is not actionable, and should not be assigned to a developer.

Let’s examine one task in more detail:

Create a registration form

From user story #1:

• As a user, I want to be able to register an account so that I can access the app.

Acceptance Criteria:

• The form should contain a username field
• The form should contain an email field
• The form should contain a password field
• The form should contain a confirm password field
• The form should contain a submit button
• The form should contain a link to the login page
• The form should contain a link to the forgot password page
• The form should contain a link to the terms and conditions page
• The form should contain a link to the privacy policy page
• All form fields should be required and validated

While this task is quite clear about the conditions that must be met, the validation requirements are not specified. This is a common problem when writing tasks, and can lead to confusion and frustration. It is crucial to catch these issues as early on as possible, as they can lead to delays and cost overruns. In this case, the team ask for documentation on how input fields should be validated, for example, minimum password length or username strategy.

💡 Markdown

md Copy

	- [ ] The form should contain a username field
	- [ ] The form should contain an email field
	- [ ] The form should contain a password field

Estimation

Once a project has been broken down into epics, user stories, and tasks, the next step is to estimate how long each task will take to complete. Estimation is a difficult process, and is often inaccurate. Typically ability with estimation scales with experience, and a common mistake is to estimate from our own perspective. It may take us an hour to complete a task, because we have done it before, but what about others on the team?

Generally speaking it is best to build in extra time (sometimes called fat) to an estimate. It is always better to be ahead of schedule than behind as this leaves more time for testing, feedback or additional features.

There are many approaches to estimating task work, but typically these follow a similar pattern of assigning an abstract value to each task in order to compare them. The most simple approach would be to assign each task with the estimated number of hours needed for its completion. However, this assumes a level of accuracy that is rarely possible. Instead, it is more common to use a scale of values to represent relative task complexity.

This scale may be numerical (e.g. 1, 2, 3, 5, 8, 13, 21, 34, 55, 89), or abstract (e.g. XS, S, M, L, XL). The Fibonacci sequence is a popular choice for numerical scales, as it allows for a greater degree of granularity in the lower values. The abstract scale is more common, as it is easier to understand and communicate. The specific scale chosen is not important, but should be consistent across the project. These are often referred to as Story Points.

Let’s consider the Create a registration form task from the previous section. This task is quite simple, and should take a few hours to complete. We could assign this task a value of 2, or S. Now let’s consider the Create a registration endpoint task. This task is more complex, and will require more time to complete. We could assign this task a value of 3, or M. Finally, let’s consider the Create a registration test task. This task is quite simple, and should not take more than two hours to complete. We could assign this task a value of 1, or XS. In each case we are estimating relative complexity, not a specific amount of time.

Velocity

Velocity is the measurement of how many story points a team can complete in a given time period. This is usually measured in sprints or weeks, and is used to estimate how long a project will take to complete.

While planning a project, we can use velocity estimations to forecast the length of the process. For example, if a team has a velocity of 10 story points per week, and a project has 100 story points, the project will take 10 weeks to complete. Velocity is not a fixed value, and will change over time. For example, a team may have a velocity of 10 story points per week for the first 4 weeks of a project, but this may increase to 15 story points per week for the remaining 6 weeks of the project.

To update the fictional example, the team have estimated the total complexity of the project to be 750 story points, split into 5 epics. The team have a velocity of 75 story points per week, and the project is expected to take 10 weeks to complete with a 5 person team. That means that each developer will be responsible for 15 story points per week, or 3 story points per day. If we assume that 1 story point is equivalent to 1.5 hours of work, then each developer will be responsible for 4.5 hours of work per day. This may not sound like a lot in an 8 hour day, but a project manager should anticipate overruns, delays, illness, absence, time spent in meetings, and other factors that may reduce the amount of time available for development. This also helps to ensure that no one on the team becomes overwhelmed without available support.

Timing

If estimation is the process of calculating relative complexity, then timing is the process of calculating absolute complexity in hours, days and weeks. The total time required to complete the project is known as the project timeline. The timeline may not align with the founders’ expectations, in which case a compromise must be reached. For example, extra functionality may be removed from the scope of work, the deadline may be extended, or additional resources may be allocated to the project at an increased cost.

In the case of our fictional social media app, the team have estimated that the project will take 10 weeks to complete with a 5 person team. The founders have requested that the project be completed in 6 weeks to align with their marketing schedule. This change means that the team weekly velocity has changed to 125 story points per week, 25 per developer per week or 5 per day. Per developer this works out to an additional three hours of workload per day. This is a significant increase, and the team have expressed concerns about feasibility and the quality of the final product. Under this new timeline, a single mistake, misestimation or adjustment could lead to a failure to meet the unmovable deadline.

After negotiations, the founders have agreed to an additional 2 developers to be assigned to the team. This brings the velocity back in line with the original estimation, without compromising the quality of the work, placing the team under excess stress or affecting the marketing deadline.

Adaptive Planning

No plan survives contact with the enemy. - Helmuth von Moltke, On War

Anticipating the future accurately is extremely difficult, and becomes impossible if we look too far out or consider too many variables. A good quality plan should recognise the high probability of change, and be flexible enough to adapt to it. This is known as adaptive planning.

In the context of development planning, the enemy is the complexity of the project itself. We make contact the moment that the planning phase ends and the development phase begins. A good plan will model reality accurately, and require only minor adjustments. For example, a contingency for launching with a limited feature set may help to mitigate the risk of a delay in development. A bad plan will require major adjustments, or may be abandoned entirely. For example, a plan that assumes a fixed timeline and scope of work will fail if the project is delayed or additional features are added. The reason for this failure may not have anything to do with the team’s performance, but because the plan was fragile and did not model reality accurately enough.

Returning to the fictional project, let’s imagine that the first two sprints go according to plan, with an average of 125 points completed per week. Unfortunately, during the middle of the third sprint, the senior backend developer falls ill. To make things worse, while testing a developer notices that the front-end is not working as expected on some browsers. At the end of week three velocity has fallen to 80 points and the total project complexity must be increased by 50 points to account for the additional work required to fix the front-end issues.

In the next sprint, to make up time, the 6 person team would need to complete an additional 105 points, or 17.5 per developer per week. This would double the team’s workload and result in burnout or quality issues. Even if this work is split across the remaining sprints, the team would still be at risk of missing their deadline should any other unexpected challenge crop up. The project manager requests an additional sprint to be added to the project, delaying launch by one week. As a compromise, the finished sign-up feature will be launched as a registration page at the expense of an additional 20 points. This adds up to a total of 125 points in the final sprint, on track with the target velocity.

Although the delivery date has changed, the founders have enough time to adjust their expectations. The team is able to continue working at the planned pace, and with a proper break the lead developer is able to return for the final sprint. This boost in capacity means that the team are able to finish a few days ahead of time an devote the remaining time to testing and debugging.

Throughout this process, the scrum master has adapted to unforeseeable challenges without compromising the quality of the work or the health of the team. The project was delivered in less time than originally planned, but in more time than was expected. Delays were communicated well ahead of time in order to allow the business to update their strategy.

Conclusion

In this lesson we have learned about the importance of planning, and how to plan effectively. We have learned about the difference between estimation and timing, and how to use velocity to calculate the length of a project. We have learned about the importance of adaptive planning, and how to adapt to unforeseeable challenges without compromising the quality of the work or the health of the team.

It should be noted that planning is a subjective and imperfect process. There is no single way to plan a project, and different teams will use different approaches depending on what has worked successfully for them in the past. In a team setting, planning is not optional and should be done collaboratively. The scrum master is responsible for facilitating the planning process, but the team should be involved in the decision making process. This helps to ensure that the team is invested in the project, and that the plan is realistic and achievable.

Additional Resources

• GitHub Issues and Projects for Teams