Project planning will largely determine the success or failure of the entire software development initiative, be it in-house or outsourced software development.
The approach to project planning depends strongly on the chosen software development model. Scroll down to see how to plan your software development project in line with the adopted model and how this model affects the project planning process.
Planning in linear models
In Waterfall, a project is divided into a sequence of phases: requirements analysis, system design, implementation, testing, deployment and maintenance. The output of each phase becomes the input for the succeeding phase. The phases don’t repeat unless there is a critical failure, which requires serious reworking and going back to earlier stages.
Planning participants: A project owner, a project manager, business analysts and a test manager.
Planning specifics: The Waterfall model calls for the necessity to specify all project requirements and create a strict plan at the very beginning of the software development project. The plan should contain a linear sequence of the work to be done by the project team and detailed outcomes to be achieved at each project stage.
The planning process: At the requirements analysis stage of a Waterfall project, the BAs interview the project owner to outline the expected project outcomes. With this info, the project manager builds and documents the sequence of all project activities.
Software project management in the V-model is similar to Waterfall, with one significant difference in the approach to planning and executing testing throughout the project. In the V-model, testing is planned and performed for every project stage.
Planning in Agile models
In Scrum, software projects are organized in sprints, each lasting 1-4 weeks and aimed at delivering a piece of functionality that addresses a user story. User stories are usually the descriptions of features from a user’s perspective or descriptions of actions that a user would like to make (e.g., upload a photo, cut a video, add data to a database).
Planning participants: A project owner, a project manager, business analysts, a test manager, development and testing teams.
Planning specifics: In Scrum, a detailed plan is needed only for one upcoming sprint. The scope of work for a sprint is taken from the backlog, which comprises all the ideas about the functionality for the developed solution.
The planning process: Before the sprint planning itself, the project owner performs backlog grooming (also known as backlog refinement). This process includes adding new user stories to respond to newly discovered business or user needs, removing user stories that are no longer relevant, splitting user stories if they are too big to do within one sprint and prioritizing backlog items for execution.
Then, at the beginning of a sprint, planning participants set up a planning meeting to agree on the goal of the new sprint. They discuss the detailed scope of work for the sprint and determine the required efforts and the expected timeframes. Optionally, business analysts can be involved to help translate high-level business requirements into the requirements for the development and testing teams.
Extreme programming (XP)
This software development model means implementing the beneficial elements of traditional software engineering practices at "extreme" levels. For example, code reviews are traditionally considered a useful practice, and, taken to the extreme, code is reviewed continuously, as in pair programming, which has become an established practice in XP. An XP project is comprised of releases, and each release consists of short iterations lasting about a week.
Planning participants: A project owner, a project manager, business analysts and development and testing teams.
Planning specifics: The planning process within Extreme Programming is called the Planning Game and consists of two stages, release planning and iteration planning, each consisting of the exploration, the commitment and the steering phases.
The planning process: During the release planning stage, project participants determine the general requirements for the upcoming release and set the time and budget frames:
- The exploration phase – the project owner provides high-level requirements for the needed feature. The planning participants jointly turn these requirements into user stories.
- The commitment phase – each user story is reworked into a piece of functionality, sorted by value and included in the plan for the upcoming release. The project participants agree on the costs and date of the release.
- The steering phase – the plan built at the previous phase is reviewed, updated (if needed) and approved.
The subsequent iteration planning stage is performed without the project owner and is aimed at specifying the tasks for the developers and testers to be done during the upcoming iteration:
- The exploration phase – the project manager translates the functionality to be delivered in the coming iteration into the tasks for the project team.
- The commitment phase – the project manager separately estimates the expected timeframes for each task and distributes the tasks among the programmers and QA specialists.
- The steering phase – if needed, the updates to the tasks are introduced, and tasks are reassigned among the project participants to avoid their overload.
Kanban is an approach to manage a software development project without clear iterations. The project activities are split into small tasks to be performed within several working days. The tasks are assigned to team members and added to the Kanban board, which is split into different columns according to the status of the tasks in each column (e.g., to be done, in progress, completed). As the status of a task changes, a responsible team member moves the task from one column to another.
Planning participants: A project owner, a project manager, business analysts, team leads of the teams involved in the project (designers, developers, testers, data analysts and so on).
Planning specifics: Kanban has no separate planning stage. The communication with a project owner in a Kanban project is ongoing, and new change requests and tasks for the project team can be discussed and added to the Kanban board throughout the entire cooperation.
The planning process: Based on the project owner’s requirements, the project manager plans which tasks should be done by the project team to achieve close-at-hand project goals. For example, designers are to design landing pages of an ecommerce website, developers are to create add-to-cart functionality and QAs are to test the website’s usability and the add-to-cart functionality. In some cases, the project owner is initially interviewed by the business analyst who gathers high-level business needs and processes them into the requirements the project manager will deal with.
Team leads receive these tasks and conduct more detailed planning. For that, they split the tasks into the short-term tasks that can be completed within one or several working days and set up task priorities (high, medium or low). Team leads add these tasks to the Kanban board and assign them to their team members.
Avoiding potential planning pitfalls
Effective planning of a software involves not only following the instructions but also considering potential planning pitfalls. As the approaches to planning differ depending on a chosen model, so do the pitfalls.
Planning pitfalls in linear software development models:
- Project plan updates in linear models call for the need to revise the full scope of the initially planned activities and benchmarks, which leads to a prolonged project time frame and increased investments. To avoid this, at the beginning of the project, the project owner should state all their business needs to be solved with the developed solution, and the BA should be accurate in translating these needs into the requirements that will be used for project planning.
- In Waterfall, it’s difficult to plan the efforts for debugging effectively. Even if testing is given enough attention to, poor code quality may result in more time for debugging and, as a result, missed project deadlines. A possible way to avoid this pitfall is to plan code quality control activities throughout the project.
Planning pitfalls in Agile models:
- With the focus on short-term planning, there is a risk of slow project progress. If too little work is planned for each iteration, the overall project goals can be deterred, although each iteration will be successful when considered separately. To avoid that, it’s useful to have regular intermediate benchmarks (e.g., establishing monthly goals and reviewing how they are achieved).
- In Agile models, a productive iteration is hard to plan without the precise evaluation of development and testing teams’ capabilities and speed, which can be difficult to do for a newly built team. As a result, the sprint can take more time than initially expected. To avoid missed deadlines throughout the project, it’s needed to monitor the teams’ speed from the first sprint and plan each upcoming sprint with this info in mind.
A few last words
Effective planning of software development process is impossible without taking into account the peculiarities of the chosen software development model. It determines who will take part in the planning process, what stages the planning will comprise and how flexible it will be.
Looking for an outsourcing partner to take over your software development project or the entire pipeline of projects? ScienceSoft is ready to support your business growth and digital transformation initiatives.