1. Teaching slides
Chapter 3

2. Chapter 3: software project management
Contents
Project planning for Waterfall projects
: effort estimation
: Work breakdown structure (WBS)
: Project schedule
: Resource planning
: Budget planning
: Project baselining
- Project planning for Agile projects
: High level planning
: Release planning
: Effort estimation
: Sprint planning
: Daily planning

3. Chapter 3: software project management
Project planning for Waterfall projects – effort estimate
Waterfall projects need complete project planning before they can be executed. The first task involves finding the effort required for all the project activities. To know total effort required for the project, complete software requirements must be available. For each software requirement, effort required to create software designs and then their implementation and testing should be done. Effort required for complex business logic implementation should also be considered. More complex a business logic means more effort required. When we have calculated estimated effort for each task then summing them up will give us figures for total effort required for the project.

4. Chapter 3: software project management
Project planning for Waterfall projects – Work breakdown structure
Work breakdown structure (WBS) is the list of project tasks with details including task start date and end date. When project is broken down into project tasks, care should be taken to ensure that each task can be managed well. For example, we need to create software designs on any software project. So we can have the main task of software design which can be further broken down into many sub tasks. A convenient way of breaking down the software designing tasks could be breaking them as per the software modules.
On the next slide, an example of a WBS is provided.

5. Chapter 3: software project management
Project planning for Waterfall projects – Work breakdown structure

6. Chapter 3: software project management
Project Schedule
Once effort estimate for the entire project is found out, we can create project schedule using Critical Path Method (CPM). Apart from the WBS we derived in the previous step, we also need information about task dependencies and which tasks are critical. Critical tasks are the ones which if get delayed will result in project delays. Task dependencies dictate if a task can start only after completion of another task. Since we know effort required for each task, we can put time duration for each task. We also need to assign start date of the first task (task with the earliest start date).
We can then put all critical tasks on a straight line one after another starting with the first critical task. We need to respect task dependencies while doing so. When we are finished with all tasks then the length of this straight line will be the project duration derived from the start date of the first task to end date of the last task. This straight line is known as the critical path for the project. All non critical tasks can be put in parallel to this critical path. Example of a project schedule is given on next slide.

7. Chapter 3: software project management
Project schedule

8. Chapter 3: software project management
Project schedule
Once a project schedule is found out then it can also be drawn in form of a graphical drawing. Gantt charts are used for this purpose. When drawing a project schedule, people make mistake of not taking care of task dependencies and criticality of tasks. When this happens then the drawn project schedule becomes wrong. One such example is being given on next slide. After taking care of task dependencies and criticality of tasks, another Gantt chart is shown on next after figure.

9. Chapter 3: software project management
Wrong project schedule

10. Chapter 3: software project management
Correct project schedule

11. Chapter 3: software project management
Resource planning
Once project schedule is ready, we can proceed to plan for resources. Each project task needs to be assigned to one or more people. A right match is needed between the skills needed for a task and skills of available resources. A good match will ensure that the project task can be done well.
One more consideration is that a resource should be available for the task duration. If a resource is partially available or not available at all during the project task then some other resource must be considered. In the next slide example of resources assigned to project tasks in a project schedule is depicted.

12. Chapter 3: software project management
Project schedule with resource planning

13. Chapter 3: software project management
Baselining the project
Once a project schedule is drawn, all the dates (task start and end dates) on the schedule should be frozen. These dates will be the baseline dates against which project and task progress will be measured when the project execution starts. When execution starts then when a task is actually completed will provide the information about the actual start and end date for the task. These actual dates can be compared with the baseline dates to find out if the task is delayed or completed in time.

14. Chapter 3: software project management
Project planning for Agile projects – high level planning
On Agile projects project planning is not done at project level. Instead planning is done at Release, Sprint and daily levels. But to have the large picture of the software product being built, high level software design aspects are important. What architecture designs can be used, what software design patterns can be useful, what software design and programming paradigms can be suitable for the project etc. must be considered. All these aspects can be considered at high level planning.

15. Chapter 3: software project management
Release planning
Software products are developed incrementally on Agile projects. For each major increment to be developed for a software product, a Release is planned. There can be many Releases for a software product. These Releases are specified by the customer. Generally software product features which are important for a customer are planned to be developed in these Releases. One example of a Release planning is depicted in the next slide. The example shows that a software product is being developed over 2 Releases. Release 1 has 2 Sprints and Release 2 has 1 Sprint.

16. Chapter 3: software project management
Release planning

17. Chapter 3: software project management
Effort estimation
Effort estimation is done inside Sprints on Agile projects. For each user story, the project team can make effort estimate using a Poker game. Each team member can analyze a user story and put a figure for effort required in form of a card drawn from a pack of cards. A consensus figure from all of these estimates will be the effort required for that user story. This number assigned to a user story is known as the number of story points for that user story. The more complex or larger a user story; the more number of story points it will have. This process is repeated to estimate effort for all user stories in a Sprint. The next slide depicts a Sprint with story points assigned to all user stories planned in the Sprint.

18. Chapter 3: software project management
Story points as effort estimate

19. Chapter 3: software project management
Sprint planning
A Sprint is time boxed. The customer decides at the beginning of the project as to how long each Sprint should run. Once time span for Sprints is set then it is never changed. Since time span is fixed, amount of work which can be performed in a Sprint is also fixed. The customer gives user stories to the project team to implement. Amount of work to implement these user stories is not fixed. So some of the user stories may not be implemented due to lack of time. In such cases, they can be carried forward to the next Sprint. To ensure important user stories are implemented in a Sprint; the customer assigns priority to each user story.

20. Chapter 3: software project management
Daily planning
To ensure project tasks are completed as per Sprint plan, some more planning is done at lower level. This lower level planning is done at day level work. Each team member plans at the beginning of the Sprint as to what activities he/she will do each day during the Sprint. During the Sprint, if a project work gets delayed then it is immediately known to the team member that he/she is late. This pending work is then planned for next day and completed. Each user story is also given a priority by the customer. Higher priority user stories are implemented by the project team. So priority of user stories help project team to create their daily plans so that high priority user stories are implemented inside the Sprint. The next slide depicts a Sprint with each user story having a priority.

21. Chapter 3: software project management
Daily planning

22. Chapter 3: software project management
Resource and budget planning
On Agile projects, there is no variability in resource demand. A dedicated project team is deployed on an Agile project. This project team keeps working on the project through all Releases and Sprints till the software product gets built completely. So at the beginning of the project, a project team is formed which works through out the project. Resource assignment is not needed on Agile projects as each project team member self assigns his/her project work.
Since a constant team keeps working on Agile projects, once budget is planned for the project; it comes good for the entire project. For example, if there are 7 team members on the project then expenses for the project will be constantly the same for every period (week/month/Sprint) during the project.