How to go about planning & scheduling an outsourced agile development project
Large Outsourcing Product Development engagements usually involve multiple teams at onsite at client location, and one or more offshore units. Applying agile methodologies to such engagements can be challenging if not applied with an appropriate planning framework in mind.
Mature software development firms use an appropriate planning framework consisting of 5 levels of planning. The components of the planning framework consist of:
- Product Visioning
- Product Roadmap
- Release Plan
- Sprint Plan
- Daily Commitment
This is a broad picture about the product as envisaged by the Product Owner. The Product owner explains how the product would look like, the broad features, the priorities and goals of the product.
With customers demanding more frequent changes and releases, the time to market is shrinking considerably. The Product owner therefore requires to think the entire development in terms of shorter steps leading to a road towards the final product. A Product Roadmap is created by the Product owner and conveyed to the development/ delivery team. The goals of the product roadmap are:
- Communicate the whole
- Determine and convey when releases are required
- Determine that the release includes appropriate functionality, each of these can be a set of features which can be clubbed together to form epics.
- Focus on business value planned from the releases
The delivery team will on the other hand realize:
- Understand the product vision
- Learn the steps to realize the vision
- Learn the priorities in business
- Provide technical inputs for the roadmap
- Provide estimates for the projected features
The Product Owner would define the Product roadmap, using a series of meetings with the development / delivery teams. A list of desired features are also built by the Product owner which is called Product Backlog. The list needs to be prioritized in discussion with the delivery team by the Product Owner, so that features can be combined into a release. Besides functional features, the backlog would also include the non-functional features, i.e. the technology features.
A release consists of a set of product increments or features that is released to a customer. A release is done at a System or Program Level and consists of a number of iterations. Releases are shown in the Product Roadmap with a date, time and planned feature set. Prioritized Product Backlog serves as an input for Release Planning. A fixed release dates are assigned for all teams of the program with a typical interval of two to four months.
The iteration on the other hand is defined at the feature level. The delivery and product owner agree on the number of iterations as part of product release.
Release planning is highly collaborative or interactive in nature and could use tools like sticky notes, flipcharts and whiteboards. This involves the Product Owner for defining user stories, setting priorities and mapping stories to iterations; and Developers, who estimate stories, point out significant technical risks and establish velocity, which is a measure of team development capacity.
A typical Release Planning meeting would have the following agenda:
- Introduction, agenda, goals and updates
- Explanation of the Product Vision by the Product Owner
- Time scheduling / time boxes of the releases and iterations
- Capacity analysis by delivery team
- Agreement on completion of deliverables
- Movement Plan of features from backlog to iterations
- Determination of dependencies and resolution of dependencies by alternative iterations.
- Final estimation of workload per iteration and comparison with the available capacity.
- Review of discovered risks and issues
- Retrospective of the session.
|Release||Iteration||Stories||Size (Story points)|
|Display Summary of users||2|
|Display user details||1|
|List Transaction Summary||1|
|Add New Transaction||2|
|2||Add New User||2|
|Deactivate and Remove existing user||1|
Fig.1: Release Plan for Release 1
Iteration/ Sprint Planning
A release consists of multiple iterations or sprints, and every iteration is therefore more granular than a release. The responsibility for Iteration Planning rests with the Scrum Master or Project Manager and the Product development Team. During the session, or before the session, details is added to each feature by dividing each of them into tasks. The core activities in Iteration Planning include:
- Determination of actual capacity, or amount of work that can be done within each iteration.
- Decomposition of features into tasks and fitment of tasks to iterations.
- Every task is separately estimated, a typical task could be anywhere between half a day to two days in effort.
- A feature is not done unless it is fully tested and confirmed by the product owner. Therefore, frequent demos to customer / Product Owner is done to ensure that product development is as per expectations. Any deviations are corrected and sprint plan is altered after confirming the change from customer or Product Manager.
- Each Sprint would necessarily consist of Analysis, Design, Build, Testing, Sprint Retrospective and Sprint Review activities.
Fig. 2: Release Planning/ Sprint Planning / Daily Scrum
Daily Planning/ Scrum
The stand-up meeting on a daily basis forms part of daily life of agile teams (read when to use agile development and when not to). The daily meeting though not really perceived as a planning session, essentially is a micro-level planning, where the members plan for a day ahead. Looking at the plan for iteration and the past, the team members tell each other what they plan or intend to do on that day, issues are raised, and possibly addressed during the meeting, action items are planned as a follow-up which become an input for next day’s discussions.
In a larger context, daily meetings (also called scrums) need to be synchronized between teams (‘Scrum of Scrums’), where representatives from each team report the status, plans and impediments to each other in the identical format.
Usually, the following three questions are answered in these meetings:
- How are the teams progressing?
- What are the cross team impediments?
- Who is taking actions to remove them?
As an example, the IT delivery teams have a daily stand-up meeting, as do the pre-production, finance, training teams and so on. On a weekly basis (or sometimes daily if delayed in the release cycle), representatives from each team meet to inform progress, impediments and plans.
Project Initiation / Kick-off
Any project requires participation of a team and it is important to have cohesion, association and understanding among the individuals forming the team.
In Outsourced Product Development, this stage of forming is important for team members as they are aware of each other’s strengths and weaknesses, and form the expectations from each member in the project. Therefore, before the team is engaged or on-boarded, a kick-off meeting is coordinated with the team members, to participate in the sprints and daily scrums, and all the supporting groups.
It is coordinated by the Scrum Master / Team Lead. All the stakeholders of the development like Product Owner, Team Lead, Team Members, Senior Manager supporting the project, and representative groups from all the groups like Tools, Technology, IT, Specialist Teams such as DBAs, Tech writers or UI designers, QA/Testing team, any additional supporting personnel (like Finance, HR, etc.) whose potential support is required need to participate in the meeting.
As discussed, the team structure for an outsourced Agile Project (see when to use agile and when not to here) would consist of a Product Owner who would typically be the customer or customer representative and working from customer’s office at onsite.
The Outsourced Partner at your outsourced software development firm would be at a remote location having the following members ideally:
- A Senior Manager representing the overall team and though not part of actual execution would be indirectly supporting the project and help in streamlining the work or removing obstacles in the process. He would also be involved in the project commercials and engagement with the customer.
- The offshore engagement would be led by a Team Lead / Scrum Lead, and supported by a Team members consisting of developers and testing team.
- In addition, the team would be supported by a Tools & Technology Group / IT Support, Specialists like DBAs, Tech writers and User Interface designers and additional developers & testers as a backup.
Fig. 3: Team Engagement
An overall Project Schedule is developed based on the sprints planned. This creates better visibility and overview of the features associated with each sprint, the priority level, the estimate in story points, the dates planned, duration in days and the state of each task / feature whether completed. This can be used for planning and tracking the project. Any Project Management / Scheduling tool can be used for this activity.
A typical example of a project schedule is depicted below.
|Task Name||User Need||Story Points||Start||Finish||Duration||State||Sprint|
|Sprint 1||26||30-Nov-15||18-Dec-15||15 days||Done||1|
|Feature 1||High||5||30-Nov-15||04-Dec-15||5 days||Done||1|
|Feature 2||High||8||07-Dec-15||18-Dec-15||10 days||Done||1|
|Feature 3||Medium||7||07-Dec-15||18-Dec-15||10 days||Done||1|
|Feature 4||Medium||6||14-Dec-15||18-Dec-15||5 days||Done||1|
|Sprint 2||24||21-Dec-15||08-Jan-16||15 days||In progress||2|
|Feature 5||High||8||21-Dec-15||01-Jan-16||10 days||In progress||2|
|Feature 6||Medium||6||21-Dec-15||01-Jan-16||10 days||In progress||2|
|Feature 7||Medium||5||04-Jan-16||08-Jan-16||5 days||In progress||2|
|Feature 8||Medium||5||04-Jan-16||08-Jan-16||5 days||In progress||2|
|Feature 9||Medium||8||Not started||Backlog|
|Feature 10||Low||5||Not started||Backlog|
|Feature 11||Low||5||Not started||Backlog|
Fig. 4: Project Schedule
Click here to know more about how we work with you on outsourced product engineering engagements