Managing Your Sprints
As a team, take some time to prioritize, organize, clarify, and assign the project's features that will be done this Sprint. In industry, Sprints often end with a demo to stakeholders, and progress is measured by how many features (i.e., things a customer would see as a reason for buying your product) were completed in the Sprint, rather than how much of the data structure was set up (or some other "technical" goal). It is your responsibility to ensure those features are well-designed and tested so that needs to be factored into how many features a team would "promise" to deliver each Sprint.
Submitting your Work
Submit your discussion summary to the file doc/MANAGING_SPRINT_N.md of the master branch of your team's provided Gitlab repository using the commit message "lab_managing_sprint_N - participating NETIDs".
Additionally, update your Gitlab project to reflect the new and updated Issues made during the Planning steps.
Resources
This series of short blog posts describes how to think about building software differently using GIT, in general, and Gitlab, specifically, to support managing your project:
The quick summary is:
Starting the Sprint
Groom your Backlog by considering the following:
- remove Use Cases that are no longer appear relevant
- develop existing Use Cases to ensure they have sufficient detail or updated information
- create new Use Cases in response to newly discovered needs or goals
- reassess the relative priority of all Use Cases
- correct existing estimates of high priority Use Cases in light of newly discovered information
The result of this planning should be an updated BACKLOG.md file in Gitlab
Planning Collaboratively
Refine your goals so that they can be reasonably estimated and turned into Gitlab Issues:
- discuss each person's honest capacity for this Sprint based on your outside of class activities (midterms, interviews, illness, etc.)
- determine the team's priorities for what needs to get done during this Sprint
- use those priorities to create a set of tasks that need to be completed (for this step just try to list as many as possible)
- collect the tasks into categories that clearly complete end-to-end features (so that a little bit of all "levels" are represented)
- for each category, estimate its complexity (e.g., using Planning Poker to reach collective agreement) including how you will know it is done
- look at the estimated categories of tasks and compare it to the limit you think can achieve in this Sprint and choose the most important ones
- once the tasks are estimated and chosen, assign them to people to work on
The result of a Sprint should be running code that is demonstrably improved over the last Sprint (ideally well tested and robust against crashing).
Documenting the Plan
Estimating the complexity of your tasks can be challenging so try making them as small as possible by breaking big tasks down into sub-tasks (since most programmers start with tasks that are too big). For each task planned for this Sprint, break it down further such that it is:
- less than 4 hours in duration to complete (feel free to use the time estimate/time spent feature if you want to improve your estimation skills)
NOTE, make sure to include coding that is not directly related to a new feature (e.g., refactoring, testing, debugging, or spiking) as well as non-coding tasks (e.g., meeting, planning, etc.)
- assigned a weight (the task's complexity (Story Point estimate), not its time)
- assigned to a team member (based on the number of hours they can commit to the Sprint)
NOTE, if the same or similar tasks need to be done by multiple people on the team, create one Issue per person for that task
The result of this planning should be a Milestone in Gitlab, populated with Issues, that accurately reflect each team member's velocity (independent of pressure from the team or others in class).
During the Sprint
By breaking tasks down to this level of detail your team (and other stake holders) will see the following benefits during the Sprint:
- gives your team a better understanding of the work involved
- prevents a team member from being over or under loaded
- easier to assign/reassign smaller tasks versus large tasks
- makes it easier to complete what was planned in that Sprint
- provides more accurate status of how the Sprint is progressing
- easier to make adjustments to the Sprints based on Client feedback, providing better customer service
- publish more accurate schedules to the Client and better manage expectations with them
This is only effective if you update your progress regularly by changing an Issue's status online through Gitlab's Issue Board or using keywords in your GIT commit messages.