When executing a large project, that involves hundreds or thousands of people, it’s important to have a vision and a plan for achieving your project goals.
Before initiating a project, following are the essential artifacts which are vital before development team can be introduced.
1. A high-level vision of the end product includes
a. List of capabilities
b. Constraints
c. A set of targeted customer segments
d. Supported scenario or
e. Or an announcement on project end date to key stake holders or a date for major press release.
2. A high-level architecture, lists various components that interact to achieve product vision.
3. A high level schedule
High level schedule consists of milestones, these milestones can be further classified as Internal or External.
a. Internal Milestones are internal to project team and should have dates for key event like finalize user interface, internal stakeholder approvals, beta launch, etc.
a. Internal Milestones are internal to project team and should have dates for key event like finalize user interface, internal stakeholder approvals, beta launch, etc.
b. External Milestones are key event dates out side the project team, these external milestones could be press release date, conference announcement dates, etc.
In-short, a high-level vision, architecture and schedule is important for project success, but it can not be overdone. Too much upfront planning tends to be a wasteful, since there are many unknowns and requirements often change.
Once you have initial high-level plan, development team need to know their contribution to the vision, architecture and schedule. This knowledge is essential to derive each team’s work backlog.
Let’s look at architecture and vision to derive this information.
Let’s look at architecture and vision to derive this information.
Here are two approaches to build backlog for each team, refer to figure as well.
• By Scenario, each team owns a different scenario described in the vision (such as book a flight ticket, auto upgrade preferred customers to business class )
The team creates components on need basis, the components get refactored by other team on need basis.
The scenario approach ensures complete end-to-end experience, but it may result in poorly engineered components constructed by too many hands.
Team’s backlog is derived by breaking down the team’s assigned scenario into individual features or stories
• By component, each individual team owns a component laid out in the architecture (such as build library, enhance performance, etc.).
The component approach provides clear boundaries for teams but may lead to in-complete end-to-end experiences.
Team’s backlog is derived by breaking down the team’s assigned component into individual features or requirements.
