Project Planning

As a software developer, you will be responsible for estimating the cost and time required to develop a software application. For each user story, you can provide an estimate of how long you think it will take to complete the development process, including design, coding, testing, and delivery. The overall project estimate will then be the sum of the estimates for all user stories.

When making your estimation, it is important to consider the time you will spend on research or learning about developing a particular feature.

Estimating the time required to develop a user story can be challenging and prone to error, even for experienced developers. This is due to a phenomenon known as the Planning Fallacy. In agile software development, practitioners use various strategies, such as Planning Poker, to combat the Planning Fallacy. However, these strategies are beyond the scope of this course.

In OOSE, we will closely monitor your progress and assist you with project planning. At the beginning, if we determine that delivering user stories in the "must-have" requirement category will take longer than the duration of this course, we will ask you to make changes, including potentially choosing a smaller project. Conversely, if we find that the project is too small, we may request that you implement some of the "nice-to-have" features.

Here are some general guidelines/expectations for planning your project:

  • In the first two iterations, focus on implementing the core requirements. These core requirements typically include all or a subset of the "must-have" features that are essential and cannot be omitted. We recommend prioritizing the delivery of these core features as early as possible.
  • For iteration 1, it is acceptable to set conservative goals and achieve them. In iteration 2, aim to accomplish more, increase your pace, and build momentum. By the end of iteration 2, you should have implemented all the core features that differentiate your application from similar ones in the market.
  • By iteration 3, ideally, you will have started working on at least one feature that is considered among the most challenging requirements to implement. This feature typically elevates your application beyond a simple CRUD app.
  • By the end of iteration 4, you should have completed all the "must-have" requirements and possibly a few "nice-to-have" ones. At this stage, the software should be functional but may still have some bugs. We refer to this as the Alpha release or version 1.0.0-alpha of your application.
  • During the last week of classes and optionally the reading break, focus on code cleanup, UI polishing, bug fixing, and software patching as much as possible. This stage is referred to as the Beta release of your application or version 1.0.0-beta.

Project Backlog

The Project Backlog (or Product Backlog) is the current list of user stories for the project. User stories should be organized into groups, such as "must-have" and "nice-to-have", and prioritized.

Assign higher priority to user stories that have the biggest impact and are the easiest to implement.

The Pareto principle (also known as the 80/20 rule) states that roughly 80% of the effects come from 20% of the causes. In software development, teams have observed that 20% of the features provide 80% of the value. Therefore, prioritizing stories based on agreed-upon parameters allows teams to deliver maximum value.

We already promote prioritization by requiring you to organize your user stories into categories like "must-have" and "nice-to-have". You can further refine these groups by identifying a subset of must-have as "core requirements" or a subset of nice-to-have as "out-of-scope" or "won't-have" categories. By making these refinements, you increase the "signal-to-noise" ratio, leading to a more successful product.

User stories can be added, modified, or removed from the Backlog during the development of your project.

Roadmap

To create a roadmap for your software development, you need to prepare an "iteration backlog" for each iteration. This backlog should consist of a list of user stories that you plan to implement in that specific iteration. By collecting all the iteration backlogs, you will have a clear timeline for the delivery of each feature.