Project Planning: How to Get Started

Wondering how to get started with your Agile project plan? Here, Tisski Delivery Manager, Sam Adkin, discusses Tisski’s approach, offers some expert advice and presents an example project plan our team might use to help them set out on the right foot.

The Six Ps

Something I’m often asked as a Delivery Manager is: How do you set about writing a great Agile project plan? After all, Agile is about being flexible, so is a plan really needed? Well, I’m a firm believer in sticking to the six Ps:

Proper Planning and Preparation Prevents Poor Performance

At Tisski, we aren’t Agile evangelists but Agile pragmatists; we have developed an approach to delivery which remains Agile at its core, while also providing additional assurances and controls designed to make Agile slot into a broader IT and business function.

If you’re looking to kickstart an Agile plan, the key is to allow for controlled flexibility and the technique at the heart of this approach is the tried-and-tested ‘sprint’ – a timeboxed (fixed length) period of effort which comprises detailed design, development, testing and project management.

Try concentrating on two types of sprint: build sprints, for development of the solution, and deployment sprints, to deploy the solution to end-to-end User Acceptance Testing (UAT), followed by live environments, and then train your users ready for launch.

The number and length of sprints will be determined by several factors:

1. The size of the project – if you’re building a new solution with a significant number of user stories, you may require a high number of sprints to cover development.
2. The type of project – some projects will be suited to several small sprints where functionality is regularly released in an MVP and continuous improvement model; others will require a single go live only.
3. The customer – purist Agile assumes the team are fully empowered to make all decisions, which can be impractical in real life. If there is an expectation that some functional decisions in-sprint will need outside decision making input, it may be appropriate to shift from a two-week to a three-week sprint to accommodate this. (Beware of any sprints longer than three weeks, as this represents too long a duration and therefore insufficient user feedback between demonstrations.)
   
   
   

Once you’ve determined the number and length of sprints, you should then begin drafting a high-level plan to pull everything together. Remember, as an Agile project, you should avoid defining what will be delivered in each sprint – this will be a collaborative decision made by the entire project team.

Key moments to map out within each sprint will be:

1. Planning sessions – this should be the first day of each sprint where all members of the team come together to define the sprint goal and plan the sprint activity.
2. Daily stand-ups – gather your project team each morning to discuss progress and blockers.
3. Weekly project meetings – separate to the stand-ups. This is a meeting to discuss progress, budget tracking and key risks and issues.
4. Backlog refinement – the most frequently overlooked ceremony. This session should be a review of the full backlog, with a focus on prioritisation and tracking against budget remaining and velocity.
5. Sprint demo – the end-of-sprint demo to the selected user community to gather feedback on what has been built ready to inform the coming sprint.
6. Sprint reviews and retrospectives – a ‘lessons learned’ exercise at the end of each sprint.
   
   

So, taking all of this into account, let’s take a look at an example build and deployment plan:

Using the above as a template, you can structure your build and deployment sprints to deliver them to a suitable frequency and duration, helping you deliver a smooth and successful Agile project which fits into a broader enterprise IT delivery function and allows for stage gate controls and sign-offs.