iceScrum

This web page is set up for the students in CS 440 at the University of Illinois at Chicago during the Fall 2014 term. Some details may not apply to other situations.

iceScrum Resources

• Main site: icescrum.org
• Online documentation: kagilum.com/documentation/
• Getting Started documentation: www.kagilum.com/documentation/getting-started-with-icescrum/
• Local server: marvin.cs.uic.edu:8080/icescrum

Creating An Account

1. Open any web browser, and connect to an iceScrum server.  For CS 440 use www.marvin.cs.uic.edu:8080/icescrum
2. Click on "connect" in the upper right hand corner.
3. Choose "Registration" on the pop-up login dialogue. ( There is no need to fill in the fields yet. )
4. Fill in the fields, noting the following for CS 440:
   • Please use your real name, and only create one account.
   • Under "username", please use your ACCC NetID, e.g. "jbell"
5. After filling out the fields, the "Registration" button at the bottom of the form will take you back to the login popup, where you can now log in with your newly created user name and password.
6. After logging in you can click on your icon on the upper right and then click "your account" to personalize your icon, change your password, or correct the spelling of your name.

Creating a Project ( With Specific Details for CS 440 Fall 2014 )

1. It is okay to create practice projects for the purposes of learning the software, as these are easily deleted later. ( Please delete unwanted projects when you are done with them, to reduce clutter. )
2. On the top menu bar to the left of the "Dashboard" menu there is another menu whose name may change depending on what project(s) you are or are not already a member of. We will call this the "Project Menu".
3. Select the "Create" item from that menu.
4. Fill in the forms, noting the following for CS 440 in Spring 2014:
   • For practice, please name your project "practice", "sample", "play", or something like it, and include your user name as part of the project name.
   • When you are ready to create your real group project, please name it "Group X Spring 2014 - Name_of_choice", where X is your assigned group number and Name_of_choice is whatever you wish to call your project. ( This can be changed later. ) Only one member of the group should do this.
   • Please create all your projects as Private. The instructors can still view them through the administrator login. ( Note that the Group 0 Sample Project is public for instructional and demonstration purposes. )
   • The time zone for Chicago is UTC-6:00, and is one of the choices on the menu.
   • Under "Find members" ( on screen 2 ) you can search for anyone who has created an account by name or user name. Note that there may be student accounts left over from past semesters.
   • Assigning roles to team members gives them differing access and authority for the project. "PO & SM" is Project Owner and Scrum Master, with the most abilities and authority.
   • You probably want to leave everything on screen 3 alone. You can change these settings later if you really want to.
   • On screen 4 it is very important to get the dates right. The "project start" date in particular cannot be changed later.
     • Project start date: Monday 8 Sept 2014
     • First sprint start date: Monday 15 Sept 2014
     • Release end date: Friday 10 October 2014. ( This is the end of the first Release only. )
     • Default sprint duration doesn't really matter, since you will change them all manually later anyway. ( 12 days works well. )
5. After the project is created you can inspect and modify parameters by selecting either "Settings" or "Practices" under the Project Menu.

Setting Up Initial Release and Sprint Dates and Details

Note: All dates are listed in one place on the bottom of the schedule page.

1. Clicking on the "Timeline" menu, you should see the first Release and either 2 or 3 sprints associated with it.
2. The down arrow on the Release has an "update" choice, that will let you change the name, description, and possibly dates of the Release.
• Release 1 dates: 8 Sept to 10 Oct 2014
3. Clicking on either a Release from the timeline or on the "Release Plan" menu shows individual sprints, with their own pull-down menus.
   • Delete the third sprint if present
4. Update the first two sprints to provide goals and adjust dates:
• Sprint 1 dates: 15 Sept to 26 Sept 2014
• Sprint 2 dates: 29 Sept to 10 Oct 2014
5. Go back to the timeline and select "+ New release" to add two more releases, the first having two sprints and the third consisting of a single sprint, with the following dates:
   • Release 2 dates: 13 Oct to 14 Nov 2014
     • Sprint 1 of Release 2 dates: 20 Oct to 31 Oct 2014
     • Sprint 2 of Release 2 dates: 3 Nov to 14 Nov 2014
   • Release 3 ( Testing ) and the sprint within dates: 17 Nov to 29 Nov 2014
6. When all is completed correctly, your timeline should look something like the following.
   • The naming of specific releases is up to you, and may vary from project to project.
   • Note: As of 4 September 2014, the following image is for the Fall 2014 semester, and may not correspond exactly to the dates provided for other semesters.

Story Creation and Migration to Product Backlog and Sprints

1. Anyone with access to the project can create stories in the sandbox. These are kind of like the users' ( stakeholders' ) wish lists. The should document as fully as possible the users' vision of what they want to do with the product. In general you want as many of these as you can get, each describing a use of the product, eg. Launch Game, Create Character, Fight Beast, Drink Potion, Exit Game, Save Game, Restore Game, etc. ( These may be associated with "Features" if the project has defined features. See the menu with the down arrow to the right of the "Sprint Plan" menu to add features. )
2. The Product Owner, PO, can do many things with the stories in the sandbox, including editing ( updating ) them, copy, delete, comment, and accept them as either story or feature.
3. Accepting a story from the sandbox moves it to he product backlog. ( Or feature list. )
4. Stories in the product backlog must be assigned a point value before they can be added to sprints. This value indicates how much having this story completed is "worth" to the product owner, and is not generally related to the effort required to realize it.
5. Stories can be dragged from the product backlog to specific sprints, but not to releases.

Adding Tasks to Sprints and Assigning them to Members

1. On the sprint plan, the "+ New" button allows for the creation of tasks.
2. Tasks can be associated with particular stories, or can be considered urgent or recurring.
3. Your group should agree on a color-coding scheme. ( By story, or team member, or priority, or . . . )
4. Each task should be assigned a time that it is expected to take. The group should agree on these values.
5. Group members may then "take" tasks using the pull-down menus.

Due by Saturday of the Third Week ( 13 September 2014 )

1. Write up a ( minimum ) one-page story describing how someone will be able to use the program at the demo on 28 February, following the example below. ( Only better - Include the project name, group number, and group members names, and if necessary a sentence or two describing the project. ) Submit this document to the git repository following instructions provided.
2. Set up a project on iceScrum as described above.
3. Break the overall story written in step 1 down into a set of smaller stories, e.g. use cases, and add them to the sandbox. Go ahead and brainstorm as many stories as you can / want, including some that probably won't get done this semester.
4. Select some of the sandbox stories, give them values, and assign them to sprints.
5. Add tasks to sprints, including estimates of time needed.

SampleScenarios from a Past Semester

Note: Student submissions should be better than these examples. In particular they should have a more meaningful project title and should include the group number and all students' names at the top of the page.

• Sample First Scenario
  • Data File Format
  • Data File Example
• Sample Second Scenario
  • Data File Format Version 2.0 - Updated from original draft
  • Mystic City 2.0 - Sample version 2.0 GDF file, with lights, keys, and other artifacts.
    • Floor plan diagram
    • Data file
• parseTest.cpp