Part D: Increment & Release Planning Flashcards
- Classic project management (max 5 points)
List the key activities and artifacts that arise during classic project management.
- Goals
- OBS (Organization Breakdown Structure)
- WBS (Work Breakdown Structure)
- PERT (Program Evaluation Review Technique)
- GANTT (Mr. Gantt)
- Budgets
- Activity
- Reporting
- Control
- Communication
- Project versus application (max 4 points)
Explain why you should take care to distinguish between “the project” and “the application” (alternatively called “the system under development”).
The application, or system under development, is just that - the system. In our case, the code, libraries, etc. This is sometimes referred to as “project” (e.g. in IDEs, “create new project”, etc.), but that is not the same as when we talk about projects in this context. Here, project refers to the entire organized effort. All the people, plans, code, meetings, etc, constitute the project.
It is important to make sure everyone is on the same page with these and other definitions, so that misunderstandings can be avoided.
- The challenges of software project management (max 4 points)
Describe aspects of software development that constitute challenges when attempting to apply classic project management ideas to the delivery of software applications and products.
Requirements:
● Difficult to specify fully & correctly upfront
● Emerge during development
● Identified once the software has gone live with real users
Complexity:
● Software, by its very nature is complex
● Lack of modularity & high technical debt make software difficult to adapt or be added to.
Uniqueness
● Little is constant between projects
● Therefore, experience does not always carry forward to a new project
● And this makes upfront estimation difficult
Project = Deadlines = Time pressure = Shortcuts = Technical Debt
- The roles in Scrum (max 6 points)
What are the principal roles involved in a project run using Scrum? What is the key focus for each of the roles?
Product Owner: - Represent the business - Represent the customer - Owns the product backlog - Priorities stories - Creates acceptance tests - Available to answer team members’ questions Scrum Master: - Scrum expert and advisor - Coach - impediment bulldozer - Facilitator Team Member: - Responsible for delivering user stories - Does all of the development work - Self-organizes to the development work - Owns the estimation process - Owns the “how to do the work” decisions - Avoids “not my job”
- Project manager’s concerns (max 5 points)
What four factors, fundamental to the nature of a project, must a project manager keep in balance? What other concerns will be a routine part of the project manager’s responsibility?
What four factors, fundamental to the nature of a project, must a project manager keep in balance?
- Function
- Time
- Quality
- Resource
Additional concerns:
- Risks
- Change
- Relationships
- Scrum meetings (max 5 points)
What forms of meeting would you expect to be involved with in Scrum? When would each generally take place?
Answer:
Scrum meetings are something that stakeholder, management, and teams hold to stay aligned each step of the project.
There are four main meetings that teams participate in during each iteration:
- Sprint Planning - Conducted by the product owner at the start of every sprint, after Sprint Review and the Sprint retrospective for prior sprint.
- Daily standup - Happens every day at an agreed-upon time and it is done standing up. Purpose is to e.g. review goals and address any potential bottlenecks.
- Sprint Review - Happens at the end of every sprint. The development team leads it and presents the work accomplished during their sprint.
- Sprint Retrospective - Held at the end of a sprint. Includes the development team, Scrum Master and sometimes product owner. Purpose of the sprint is to reflect on the previous sprint, and discuss “what went right, what went wrong, and what teams could do differently to improve collaboration in the future.
- Scrum master and architect (max 5 points)
It has been suggested, for a specific project, that the same individual in a development team undertake the roles of both scrum master and architect (or technical lead). What problems might arise? How effective do you think this arrangement will be?
I think this arrangement would not be optimal. The role of the scrum master is to focus on the scrum process, and coaching the team members. The scrum master’s responsibilities lie outside of the team.
There might well be a conflict of interest. If there is time pressure to deliver, it is possible the person will prioritize their architect responsibilities over the scrum master ones, resulting in a less organized and efficient process.
- Sprint duration (1) (max 5 points)
A development team is about to embark on a new application project. They need to decide on their sprint duration. What length of sprint would you use as a default? Discuss the factors they should consider in making their decision.
1 or 2 weeks would be my default (assuming the team is working 100% on this project).
It is important not to make the sprints too long, as this introduces some issues. It is difficult to plan for a long sprint. Things can crop up and estimations can be off. With a shorter sprint this is mitigated.
Shorter sprints also mean more frequent feedback to the product owner.
The sprint should also not be too short (e.g. 2 sprints per week or something), as this will make the process feel rushed. There is some overhead involved in scrum (meetings), and they can take up a larger share of the time if they need to be held more often.
- Sprint duration (2) (max 4 points)
The general view that sprints be of the same, i.e. fixed, duration. What considerations may point to using variable durations?
Easier planning. You don’t need to fit the work into the sprint, but can adapt the sprint to the real work that needs to be done. It can be easier to complete functionalities, and not having to stress to be done within the sprint.
There are disadvantages though (losing the “rhythm”, stakeholders not getting as regular feedback, etc.), which should be taken into account.
- Mythical man month (max 4 points)
The phrase “mythical man month” was coined by Brooks. What does it mean and what is the significance for software project management?
It means that the possibility of measuring useful work in man-months is a myth. Adding more people to a project does not make it finish faster.
Complex programming projects cannot be perfectly partitioned into discrete tasks that can be worked on without communication between the workers and without establishing a set of complex interrelationships between tasks and the workers performing them.
Therefore, assigning more programmers to a project running behind schedule will make it even later. This is because the time required for the new programmers to learn about the project and the increased communication overhead will consume an ever-increasing quantity of the calendar time available.
- Release planning (max 5 points)
How would you distinguish between an “iteration”, an “increment” and a “release”? What would you need to consider when planning a release?
Iteration: ● A period of time ● Delivers working code/software ● Scrum: “Sprint” ● DSDM: “Timebox”
Increment: ● The code delivered out of an increment ● Difference between old and new code bases ● Should meet acceptance criteria ● Should satisfy the definition of done
Release:
● A new code base that has been put live
● Usually a collection of increments since last release
Planning a release: ● Should be driven by business need ● Should contribute to Return on Investment ● Technical factors to consider: ○ Need for help/user manuals ○ Need for user training ○ Need for marketing/awareness ○ Need for data cleansing or conversion ○ Need to remove build scaffolding ○ Need to remove testing infrastructure
- DSDM Time boxing (max 4 points)
What is meant by the term “time boxing”? What is the equivalent term in Scrum? What advice would you give to a team when deciding what new work to include in a time box?
Time boxing is a determined amount of time something is allowed to take. In Scrum, the equivalent to this is the sprint. The length of the sprint is decided ahead of time, and the contents of what to achieve in the sprint are made to comply with the sprint length.
The team should prioritize their backlog, and start with the ones of top priority. The backlog items should also be time estimated (e.g. through planning poker), to determine how much work to include in the coming sprint.
