FAQ

Q: We're a little confused about the exact start date for the official first sprint. Does it start in week 3 or week 4?

A: Since each team may meet with me on a different day of the week, the start date will vary from team to team. My intent is that you will have your sprint plan done by 11pm the night before our week 3 meeting. Your sprint would begin the day of our week 3 meeting and last until 11pm the day before our week 6 meeting. The second sprint for the fall quarter will begin the day of our week 6 meeting and last until 11pm the day before our week 9 meeting.

Q: Do we each have a catch-all overhead issue, and if so, what should we put for estimated hours? Or, should we have specific issues; ie, something like a Plan Finalized Project issue and/or a Write Formal Project Proposal Report issue?

A: You should try to create specific issues for what you plan to do instead of having a catch-all. I want you to plan out what you will be doing for the week (or three) so that it is clear to everyone on the team what each person is responsible for doing. You can make adjustments as necessary, but you should start with a reasonable plan for who is doing what. You can have one issue for meetings that you all log time to.

Q: Do we need to put in 10 hours to senior design every week, or should we just average 10 hours a week over the course of the quarter?

A: Average. I anticipate that the actual time spent on senior design will vary from week to week. Averaging 10 hours per week across the quarter is fine. However, it is important to communicate with the rest of the team so that you don't end up in a situation where someone reduces their effort in a week when others are counting on the results of their work.

Q: We were wondering if descriptions are required for issues that we create? Both research ones and regular PBIs.

A: Yes. Research ones (spikes) should begin with a description of specific things you hope to learn by doing the research. Once work has begun you can add comments describing the approach you took and what you discovered. Alternately, you can provide a link to a wiki page that describes this, if you have a significant amount to report.

For the PBIs, you should have a description of the user story that describes what will be possible once the PBI is complete and acceptance criteria that makes it clear when the PBI is done. A helpful thing to think about when writing the acceptance criteria is "do I have what I need to write all appropriate tests for this PBI?" In the first few weeks, focus on detailed documentation for the PBIs that you plan to complete in the first few sprints. You can flesh out the ones that will likely be completed in the winter and spring when you get closer to starting those PBIs.

Each issue should include a list of tasks needed to complete the issue. Tasks should take 2 to 5 hours to complete. Once work has begun on each task, comments should be added describing the progress that is made whenever time is logged to the task.

Q: How do we estimate and track time in GitLab?

Use /estimate and /spend. See this page for details.