Agile development: How to plan for complex projects
4WEP_Siddhartha_Sood 0600004WEP Visits (5827)
Agile development is often deemed best for projects having variable scope with prioritized backlog, low number of critical dependencies on other applications, limited or no regulatory requirements, subject matter experts availability, technology, teams level of experience with Agile. When any of these boxes are not ticked, teams often find it challenging and difficult to use Agile development and move over to other traditional development methods like waterfall.
My thoughts in this blog are based on experiences and best practices which have been incorporated within my project to deliver complex proj
Prioritized backlog - The first step in project planning for complex projects is arriving at a prioritized backlog of user stories from Product Owner. You could use MOSCOW method to successfully prioritize all user stories as 'Must have', 'Should have' and 'Could Have'. It is best to have such an analysis done during project initiation stage how ever if scope changes during the course then product backlog can be further refined.
Release Planning - Another very important exercise which should be conducted upfront during project planning is breaking down the whole release in terms of iterations. A best practice could be going in reverse order from production deployment. A release planning is best done as a joint workshop between Client and delivery SME's including project leads and Manager. Release planning workshop outcomes are:
Once the workshop is over, a finalized release schedule should be published to all project stake holders, internal project wiki's, team rooms could be used.
Team Availability Calculation - Yet another very important upfront activity during project planning to be done by Project Manager is to identify how much effort can be delivered for this release. Key inputs to this activity will be release planning schedule. There are several factors which should be considered while coming up with team's availability and should be very close to being accurate. These should be:
Considering all such factors and anything else applicable within your specific projects would help get the most accurate count of team's availability for particular iteration and release. It is understandable that at times vacations and trainings cannot be predicted in advance, how ever forecasting them helps come up with realistic availability for the whole release which can be refined further before start of each iteration.
Backlog review workshop - Though product backlog comes from Product Owner, it is best to have a prioritized backlog review workshop between clients and delivery SME's to understand why certain items are classified the way they are. This helps delivery teams get a feel of overall scope and complexity of the whole release. Such a workshop should also be used to discuss each 'Must Have' user story at a high level between business and delivery SME's. This helps the delivery SME's to understand the business reasoning behind each user story.
User story decomposition (Com
Reuse consideration - Once all high level components are identified for 'Must have' user stories, Architects and leads should evaluate any reuse considerations for new or updated components. Reuse is a major accelerator for Agile development methodology based projects and often helps with producing things faster, cheaper and with minimal bugs.
High level component sizing - Once all 'Must have' user stories are identified and decomposed into components and reuse considerations have been made, it is a good idea to size these components. At this point, the business requirements are not known and hence teams should stay away from doing a detailed estimation. Several techniques as deemed fit could be used for performing this high level sizing example: Planning Poker could be used with Fibonacci story point estimation, A simple scale of Low effort, Medium effort , High effort , Very High effort could be used. All these can be referred as Rough order of Magnitude (ROM) sizings. Remember that at the end of this exercise all effort should be converted into a unit of measurement. This unit of measurement should be same as the unit which is used to measure 'Team's availability' above. It could be 'Story points' or 'Hours'.
Sizing Fit-Gap Analysis: Once team availability is calculated and high level component sizings are complete then one of the two scenarios can happen. There would be no risks if all 'Must have' user stories fit with team's availability. How ever, if teams availability is less than component ROM's then appropriate risks have to be raised and project stake holders need to work towards mitigating these risks. There could be several ways which can be used to mitigate such risks but those are really out of scope for this article and is left on Project Manager's best judgment and experience.
Note: As user stories get defined and become clear during the course of release, you would start converting and replacing these ROM estimates with actual estimates. This is an iterative exercise and should be done once during every iteration so that you have a visibility of any gaps with respect to sizings for 'Must Haves' and corrective actions can be taken sooner.
Interface/component dependencies: Another important activity which architect or leads need to perform is to identify dependencies between various components and interfaces. These could be internal to the application or for partner/dependent applications. This should be considered important from several perspectives:
Sprint planning: Once Interface/component dependencies are identified, it is time for Project Manager to sit with Product owner and create a sprint/iteration backlog for all iterations planned for the release. Several factors which should be considered while creating a sprint backlog is:
While we often look for a user story to be delivered in the same iteration as planned there could be situations where upfront analysis or design is required. In many such cases, the same user story could be prioritized for more than one iteration.
Figure 1 a pictorial representation of all these activities which represent the bulk of initial planning and analysis for delivering complex projects using Agile development methodology .
Summary: Initial and upfront project planning is critical for successfully delivering complex projects using agile development. This article touches upon some of these planning activities which I have found useful in my experience. Some or all of these activities may or may not apply in certain scenarios and project teams are free to tailor them as per their needs.
This article does not cover further agile life cycle activities like agile meetings, agile iteration planning and monitoring, tools usage etc which I hope to cover in a subsequent edition.