Planning and initiation of an agile digital project

Skipping the planning and initiation phase of a project is often justified by agile project models, but high-quality project preparations are not in conflict with agile development – quite the contrary.

North Patrol is a consulting firm specialized in the design of digital services and information systems. We shape ideas into a vision and service concept, find the best architectural and technological solutions, design a functional user experience, and compete to find the ideal partner for implementation work. We do not sell implementation projects, nor do we sell licenses; we are genuinely on the side of the customer.

19 April 2021

Sami Kalanen

Most agile project methods start with the assumption that the plans for the project's vision and key decisions are done prior to the agile implementation, and detailed planning is done as part of the implementation sprints.

In agile methods, however, the steps of planning and initiation work are often described very lightly, or it is simply assumed that the guidelines have already been made before the project is launched. This often leads to the misconception that agile projects do not involve any preparatory work at all.

The product owner can't come up with requirements based on nothing

In agile methods (such as Scrum), the product owner has the demanding role of communicating the needs and priorities of the organization to the implementing party. In particular, technical suppliers often expect the customer's product owner to describe all the requirements of the project and to answer all questions on the go.

However, creating a project development queue, or a backlog, requires a vast amount of collaboration, planning, and documentation within the customer organization. The project requirements aren't usually just made up by the product owner, but they are based on the needs collected from users and the organization as well as the design work based on these needs, which often involves large teams.

The work done during the planning phase of the project serves as a basis for more detailed initiation and allows the product owner to work independently, once the project guidelines have been defined in advance within the customer organization.

Documenting the planning and initiation of an agile process

Agile methods emphasize a working software as a priority, and documentation does not have the same intrinsic value as in many more traditional models. This doesn't however mean that the agile project would not involve planning and documenting the plans. Planning is done continuously, both before starting the project and throughout it.

The following figure showing the Microsoft Azure DevOps Board´s documenting hierarchy, based on Agile Alliance´s model, is a good illustration of the hierarchy created by project goals and requirements.

The plans at the top level (Portfolio Backlog: Epic, Feature) describe the project's goals and key functional requirements, which are determined before starting the project. Plans at this level are usually outlined during the prestudy phase of the project.

The plans of the implementation phase (Backlog, User story, Task) on the other hand deepen the definition of the requirements and fine-tune the details of the implementation. They are specified as the implementation goes on. The requirement specification which is prepared before starting the implementation serves as a basis for the plans of this phase.

Documenting the plans of an agile project
Figure 1. Documenting the plans of an agile project.

(Agile process: https://docs.microsoft.com/en-us/azure/devops/boards/work-items/guidance/choose-process)

Planning and initiation in a Scrum project

The most commonly used project model for agile software development, Scrum, uses backlog sprints for organizing and managing the implementation. Scrum gives surprisingly little guidance on how to organize design work before and during a project.

The project model assumes that the project has a vision, but does not specify how the vision is created. The project model also assumes that the project owner creates and prioritizes the backlog, but very little is said about how the project owner does this.

Another thing not included in Scrum is the role of architecture design (or the architect). Architecture is expected to be formed agilely through team work. However, for the project to be successful in practice, it's desirable to at least have a rough idea of the architecture before the project starts.

Neither does Scrum have a set operating method for user interface or visual design.  They are assumed to happen within the implementation team as part of the implementation. This is inconsistent with practice, as the client organization rarely wants to start implementation without seeing any presentation of the desired end result or how the final product is thought to operate.

Planning and initiation phases are nearly always required in order to launch a new project, but the design work isn't usually visualized as part of the Scrum process as instead it´s hidden inside the role of the “almighty” product owner.

The next figure roughly illustrates how the planning and initiation work done in the prestudy and requirements specification phase practically work as the starting point for the Scrum project.

Prestudy and requirements specification as the basis for Scrum project
Figure 2. Prestudy and requirements specification as the basis for Scrum project.

(Scrum process: https://scrumstudy.wordpress.com/2014/07/24/what-is-scrum/)

Prestudy confirms the starting points of the project

Regardless of the used project methods, before starting a new digital project, it's always worthwhile to specify the goals and scope of the project by making a prestudy, which serves as a basis for more detailed project planning and implementation work.

The aim of the prestudy is to clarify the goals of the project and the long-term vision of the resulting solution, as well as the concrete concept of the first phase. The second task is to create adequate guidelines for the project about the architecture of the solution and the technologies used. The third key task in the prestudy phase is to create the budget and schedule for the implementation of the project.

A good prestudy includes the following aspects:

  • background and goals 
  • initial service concept and key requirements
  • architecture and technologies
  • workload and costs
  • project phases and schedule (the roadmap)
  • project resourcing, organization and management

The prestudy phase can be used to identify needs, for example through interviewing the users and other stakeholders as well as trying out solution options with prototypes. Perhaps the most important task of a prestudy of an agile project is to identify what is expected from the first published result (MVP) of the project. 

The use of agile methods is often justified by the fact that large, complex systems cannot be planned in advance. Planning the details can well be left to the implementation phase, but especially in large development projects, a clear vision and architectural solutions are paramount for a smooth process of the agile implementation and successful outcomes.

(This article has been translated from the Finnish original. Read the original article.)

Sami Kalanen

Sami Kalanen, M.Sc. (Eng), is an expert in project planning, requirement specification, and tendering.

Sami consults with customers on project preparation and definition of requirements, and supports customers in competitive bidding and oversight of vendors’ implementation work. His areas of specialisation include broad, technically challenging web projects and competitive bidding in the public sector.

Sami has been working with web projects since the mid-1990s. Earlier in his career Sami worked in IT procurement at a large industrial company, in management roles at software vendor companies, as Managing Director and a partner at an independent consulting firm and as product manager for a telecommunications operator.

Customer service channels

Are you building a membership service, a targeted audience service for a selected group, or a digital service intended for carrying out a single transaction process? North Patrol's team helps you find the right solutions and technology choices to engage customers, streamline processes, ease customer service workload and minimize lifecycle costs.

Read about our services

Request a quote

About North Patrol

We are a team of ten consultants, all of whom are experienced designers and technology experts. Every year we design and prepare over 50 different online services and information systems. Our customer satisfaction is very high (9.5 out of 10), and we have helped many customers transform their digital services.

Read more about us

How we differ from our competitors?

  • We specialize in digital service design

    We specialize in high-quality design and requirements specification of digital services. Our mission is to help customers succeed in their software project by creating the best possible foundation for implementation – whether it is an agile implementation done inhouse, a project done with a partner, or a publicly tendered project.

  • We don't sell coding or licenses

    Many software companies recommend software solutions that they also implement themselves. We don’t do that. We don’t do software implementation projects or have partnerships with technology providers. Our perspective on the software market is broad, as it should be for our customers. Our goal is always to find the best possible software solution for our customer, whether it’s a custom-built solution, a SaaS service, an open-source platform, or a combination of these.

  • We are realistic and forward-thinking

    We design digital service concepts, implementation methods and architectures that are sustainable and can be further developed. We place great importance on the feasibility of software solutions, the availability of good partners and the predictability of costs.

Back to top