Backlog

Your system backlog is the prioritized list of features that you have not yet implemented in your system. The system backlog can grow and shrink throughout development, and it won't necessarily be empty by the time you ship your final system.

Your system backlog starts with all the functional requirements you identified in Milestone 1. You will soon include more items in your backlog as you refine those functional requirements and add security requirements. Your new, smaller functional requirements become items in your backlog. Your security requirements do, too. Every item should be testable: it must be possible to decide when you are done implementing an item. You might also find it helpful to associate a numerical priority with every item.

System backlog items should be more about what than how. But it's okay (especially as development proceeds) for the "how" to become a little more prominent. The key is to stay user-focused (how does this item benefit a user of the system?) rather than developer-focused (what code do I need to write?).

Sprint Process

Planning a Sprint

At the beginning of a sprint, choose the system backlog items that you want to implement as part of the current sprint. (It's a good idea to choose based on priority. Your most important features should be implemented earliest.) Break down those items into specific design and implementation tasks. Tasks are where you (at last!) get to specify how you achieve what the items require. Good tasks are small enough to be implemented by one person in about one day. Tasks don't need to be reported in your Requirements Document.

You might find it helpful to estimate how much person-time each item (or its tasks) will take. Compare that to the amount of time you have for the sprint. If you don't have enough time, reconsider whether that item should be included in the current sprint.

Good planning is key to success, so you're encouraged to spend several hours planning your sprint.

Security in a Sprint

For each functional requirement you choose to implement as part of a sprint, you need to consider any new security requirements it entails. Invent security requirements, which become new entries in your system backlog. You might implement functionality for the security requirements at the same time or after you implement functionality for the corresponding functional requirement.

Executing a Sprint

Your team should allocate tasks to members and complete them. You might find it helpful to have frequent, perhaps daily, meetings or conference calls of just 15 minutes to keep each other apprised of where you are on tasks. You might also find it helpful to keep your task list organized in some digital form—as simple as a Google doc, or as structured as a bug tracker. But ultimately, it's up to your team to decide how best to organize your own work.

At the end of your sprint, your goal is to have completely implemented the system backlog items you chose, including documentation and testing. However, you might encounter setbacks that leave you unable to finish all the items you originally chose. In that case, your focus should be on completion of some subset of your chosen items, rather than making partial progress on all of them. Any items only partially completed should remain on the system backlog and be completed in a future sprint.

Delivering a Sprint

At the end of a sprint, you deliver and demo a working system to the course staff. We help you evaluate what you've accomplished, and we talk about where you should concentrate your efforts in the next sprint.

As a team, you might find it helpful to hold your own self-evaluation of the sprint. Discuss among yourselves what worked well, and what got in your way.

Report

Your final task in a sprint is to write a sprint report, which should contain the following information:

Activity breakdown

Each member of your team should contribute a short description (no longer than a paragraph) of his or her primary activities during this sprint, including an estimate of how many hours he or she worked. (Don't be afraid of reporting numbers that seem low. Your grade will not be affected by this number. We promise.) Each member should also assess whether these activities were a valuable use of time. If not, what could he or she have been doing instead?

Productivity analysis

Compare the plan for your sprint to what really happened. Did you do what you planned, or did you do something else? Did all of your chosen system backlog items get finished? What took more time than you expected? What took less time than you expected? Most importantly, how will you change the way you work in future sprints?

Don't go overboard: this should be a single PDF that's just a page or two long.

Scrum

This software development methodology is known as Scrum. It's an agile methodology that's well suited to course projects. If you want to know more about Scrum, there are many resources available on the internet. What we're calling a "system backlog" is usually called a "product backlog" in Scrum.