Focuses on the team, project and process management aspects of software development
Can be used as a wrap around for other agile practices that cover technical concerns Scrum Roles
Work Management
Releases
Scrum work is organsied around the release of features, and these are marked by Release Planning Meetings Consists of 2 or more Sprints
Sprints
Each sprint normally lasts between 1 and 3 weeks
It starts with a Sprint Planning Meetings and ends with a Sprint Review Meeting and Retrospective Meeting In addition to this Stand-ups ( Scrums ) can take place during a sprint
Some teams will start their first sprint with a project launch meeting
Scrum Workflow
Backlog:
All the potential items to be implemented
Sprint Backlog:
The items chosen to be worked on during the sprint, typically based on what is decided to be most important This gets worked on, and then reviewed at the end of the sprint by the customer or other stakeholders
Review
• Review the progress on the project in the Sprint Review Meeting • Review the software team’s process in the Retrospective Meeting
Meetings
Project Launch Meeting
Determines the major features to be delivered to a customer over a series of sprints. Goals:
- Understand customers long term objectives and identify a minimum viable product.
- Decide on the goals for within the project course.
- Develop an initial set of user stories.
- Refine the user stories into tasks and populate a backlog of issues on GitLab.
- Triage items in the backlog to establish cost estimates and priorities.
Release Planning Meetings
Longer projects will comprise multiple releases, each of several sprints. Goals:
- Identify the high level set of features or improvements to be delivered in a release.
- Create a roadmap of milestones aligned with your customer priorities and the customer days.
- Populate the roadmap with key features from the backlog.
Assume that these will be changed in the sprint planning meetings.
Sprint Planning Meetings
Typically between 1-2 hours
Decide on main goal for the sprint.
- Major new feature set
- Performance or other enhancements
- Bugs to be corrected
- Code to be improved
Select tasks from the backlog on your issue tracker that match the goal. Ensure all selected issues are sufficiently detailed.
- Cost estimates
- Priorities
- Assignees
- Ensure that task cost estimates are within the project velocity.
Project Velocity
This is a burn-down chart:
Initially falls behind then moves ahead.
Measures effort available
Sprint Review Meeting
- Deliver and demonstrate new version of software developed over the course of the sprint.
- Summarise progress compared with planned work for sprint.
- Additional work completed
- Missed features
- Explain reason for deviations from plan.
- Identify new features to be added to the system.
Retrospective Meeting
Overall, retrospective meetings are critical for promoting a proactive approach to problem-solving and for fostering a positive, adaptive team culture. They ensure that the team continues to evolve and improve with each sprint.
Participants is normally the whole development team. Scrum master often acts as a facilitator, particularly in new teams. Some teams include the product owner or even the customer, although this can make data gathering harder.
Duration can vary, but should be at least 30 minutes if done properly (to allow for data gathering) and should be longer for longer sprints. Maximum time should be half a day.
Artifacts are better for objective evidence of problems, but may need to be interpreted carefully. A sudden increase in defect reports may be because an inexperienced colleague has joined the team, who is still learning quality assurance practices.
Team members can provide very detailed and reflective insights. Gathering data from team members also helps to get buy in for subsequent actions. Of course, team members will have subjective view points, so this needs to be validated.
-
Reflect on the Past Sprint: The team discusses what happened during the sprint, focusing on three main questions: What went well? What didn’t go well? What could be improved?
-
Identify Improvements: Team members identify specific actions that could help improve their process, tools, and interactions. This might involve addressing any obstacles that prevented the team from achieving their sprint goals.
-
Plan for Implementation: It’s not just about identifying improvements but also committing to actionable steps. The team agrees on the most important actions to take and incorporates these changes into the next sprint.
-
Enhance Team Dynamics: Retrospectives foster a culture of openness and trust, encouraging team members to express concerns and share their experiences openly without fear of blame.
-
Promote Adaptation: The meeting supports the agile principle of adaptation by allowing the team to modify their practices and behaviors based on real-world feedback from their work.
Retrospective meetings can become stale - important to:
- Vary the structure
- Reflect on the retrospective itself
- Experiment with different frequencies
- Allow other team members to facilitate
Gathering Data From Team
General method:
- Team members populate the a template board independently using sticky notes
- Similar items are grouped together
- Team votes on priority issues for discussion
- Discussion to reveal the root cause
- Select actions for improvement
A variety of templates for data gathering, e.g.:
- Stop, start, continue
- Mad, sad, glad
- Loved, learned, lacked/longed for
Stand-ups ( Scrums )
Hold a stand-up at least once a week in TP3 during semester 1. Facilitated by the scrum master. Each team member is asked:
- What did you accomplish last week?
- What are you working on now?
- Do you have any blockers?
Should not last more than 10 minutes Try documenting the stand up on your wiki to begin with. Experiment with more frequent stand-ups, particularly early on.
Managing Delays
Ask for extension: Risky because we delay the opportunity for feedback, things can change
Reduce feature set More sensible for achieving goals, things can be implemented later
Change resources required
- Reduce code quality:
- Risky later as things could need more work later, could have critical bugs
- Increase the resources available for delivery
- Has its own problems
Mythical Man Month
Only tasks that are partitionable see an improvement from adding extra people/resources, and even in practice, each person added to a project requires training, meaning it isnt a linear decrease
Unpartitionable tasks do not see any improvement
Most tasks are somewhere between, and can see some improvement intially, however after too many new people are added, communication goes down and therefore the total cost goes up
