Planning proves highly useful BUT sticking to the plan uncritically, for the plan’s sake, isn’t the wisest thing to do. In your management methodology, you should take into account changes, inventions, and new ideas that will let your project thrive.
The biggest misconception
It’s a common fallacy that you can plan everything in a project in advance. Nothing could be further from the truth. Firstly, because we aren’t the best at estimating the amount of work that has to be done (we’re way better at comparing tasks). Secondly, we should adjust and refine the plan throughout the project. Thus, we divide projects into smaller, feasible bits and define work priorities.
INVEST in stories
The key to a good estimation is a precise definition of the requirements. We can achieve this by creating user stories. User stories explain features in a general way, from the perspective of the end-user, demonstrating their real value. Creating them with your team remember not to use technical language – stories should sound as natural as possible to facilitate team communication. Above all, post-planning tasks should be clear to the team.
The most common template for creating user stories, though not the only one, is:
As a [role, e.g. client, product owner], I can [capability, e.g. browse items, monitor client behavior], so that [benefit received, e.g. I can find what I like, I can offer clients best-fit products].
Let’s take our learning management system Samelane as an example. The user stories can look like these:
– As a learner, I want to browse all courses available, so that I can find the most valuable ones.
– As a learner, I want to get notifications about course deadlines, so I can complete them on time.
– As a team manager, I want to be able to track the learning progress of each employee, so that I can offer them help or praise their achievements.
To make sure your story is ready, we use INVEST criteria. Thus, the story has to be:
- Independent – it can be realized on its own, it’s not dependent on another story, so we can change its priority freely
- Negotiable – we can still discuss and improve it if some requirements change
- Valuable – it has to add a value of some sort – to stakeholders or end-users
- Estimable – we have to be able to evaluate its size so it can become a part of an iteration
- Small – its scope has to be small enough to plan its development easily and accurately
- Testable – there has to be a measure to check whether it works/has been realized.
Prioritization
All requirements might seem important, but we can’t deliver everything at the same time. Functionality hierarchization helps us determine what will bring the greatest value to the project. For functionality to be taken on in the next sprint, a product owner together with a client should identify priorities of individual requirements.
Tip 1
It’s important to go through the prioritization process before sprint planning. It will allow the team to plan its work in a way that will reduce the risk in the event of failure to deliver key functionalities.
Tip 2
Provide your team with the list of prioritized tasks before the refinement or planning. This way they can get acquainted with them, prepare questions and initial technical solutions.
Must, should, could…
To make sure that priorities are identified properly, you can use the MoSCoW technique. It allows you to separate requirement significance easily based on four categories. MoSCoW is often used in agile software development when deadlines are fixed (timeboxing) and the team has to focus on the most important functionalities only.
These four categories are:
- Must have – critical in the ongoing delivery
- Should have – important though not crucial
- Could have – desirable but far from critical
- Won’t have – can be dropped at all or included in the next sprint
An example of MoSCow technique when building a particular functionality – here registration:
| Priority | Description | An example |
| Must have | If the requirement isn’t achieved, the functionality won’t be valid or function properly. | Password validation, verification if the user already exists |
| Should have | The requirement is important but doesn’t jeopardize the legitimacy of the business functionality. | A thank you email that is sent after registration |
| Could have | The requirement will increase business value but its lack won’t be noticed by the end-user. | Registration with a Google account |
| Won’t have | Requirements that are legitimate for functionality, but will certainly not be addressed in the following sprint. | Registration with a Facebook account |
The client vs the team
It might happen that the priorities chosen by the client aren’t in line with the development team’s technical needs. Why is that? The devs’ order may result from technical dependencies between the tasks. Commonly, teams force particular task realization to keep the code in good shape. These are tasks often related to refactoring or paying technical debt off.
Naturally, clients won’t see business value in such tasks because they don’t bring tangible effects (though the consequences can be grave and they should know about it). As always in similar situations, the way out is communication. The client and the team have to come to a compromise to fulfill both sides’ tasks, not to build technical debt up.
Sprint planning
In Scrum, every iteration ends with a value that should bring the product closer to succeeding on the market. Thus the tasks are organized according to their business value. The overall plan can be adjusted if the product doesn’t go in the right direction.
Sprint planning takes place (surprise, surprise!) during a sprint planning meeting, in every sprint. Knowing the sprint’s aim, the team meets to decide what they can achieve in the following weeks. To do so, they analyze tasks defined in the backlog and create a delivery plan.
During planning meetings, the following elements may affect the course of the sprint (worth taking into account!):
- holidays
- dependencies between tasks
- project resources
- dependency on external entities
- time for product releases
- meetings
- taking care to minimize the technical debt.
Based on previous sprints, we should be able to quite accurately estimate the next one. For example, if a team of 4 developers delivers on average 20 story points/a sprint, when 2 devs have a holiday, 2 left should in theory provide about 10 story points.
It is worth noting that the key in sprint planning is to leave a buffer that will allow you to respond to changes, fix bugs, adjust after a code review, etc. While the drive to increase velocity is important, we should always plan in a way that the sprint goal is not threatened.
Here’s an article on distributed team management using Scrum, which you might find helpful as well.
Planning poker
Planning poker, or Scrum poker, is a quick and reliable estimating method based on consensus. Team members make estimates playing cards with numbers from the Fibonacci sequence (1, 2, 3, 5, 8, 13, etc.). If the revealed cards are similar, up to three consecutive numbers – we calculate the average. If there’s a greater spread, those who chose extreme cards explain their decisions – and the team plays poker once again. It’s worth noting that the method is used for estimations not developing definite plans.
That’s it for now. I hope you’ll find these methods useful and if you’d like to find out more on Scrum, here is Welcome to Scrum part 1 and Welcome to Scrum part 2 articles.
