First of all, you define the project name and project key (a human-friendly identifier that will uniquely identify your project).
When you create a project, you get all the permissions on it, which is equivalent to being Project Owner and ScrumMaster.
If you have already created a team you can choose it. Otherwise, you can create a new one by typing a new name. If you create a new team, you will be automatically included as ScrumMaster and you can add new members. Otherwise, the members are already defined and they cannot be changed here so you can skip to the next section.
Team: In a new team, you can look for new member in the search bar and choose the role:
Project members: Here you will define the Product Owners and Stakeholders of your project:
Default practices are well suited for getting started, let’s keep them for the moment.
Finally, you can define the lifecycle and to start the first release. By default, sprints last 2 weeks (14 days). If you check the box Create the first release and its sprints. The wizard will suggest that the first sprint start the day of the project creation; by changing this date, you can define a period before the sprints start, frequently called sprint zero. A release is planned, with a default duration of 3 months, starting the day of the project creation too. You can also add a vision to the project.
After this last step, the project creation is done. Let’s give a look at the result!
You can now have a look at the result in the Planning view that has been initialized with the creation of the first release and its sprints, according to the default durations, in the step 4 of the wizard. Of course, release dates can be modified later and other releases can be created.
The Planning view shows the life of a product in the long-term, presented along the timeline, with the successive releases and the sprints contained in these releases.
In iceScrum, features are managed in an independent list: the features list or features backlog. For a new product, a top-down approach is often used, by starting with the definition of features.
A different color can be used for each feature in order to ease the identification of stories associated with this feature. It is also possible to use the value attribute to describe the added value of the feature, give it a type (functional/architectural), a tag, a description and add notes to it.
When you add a new story, you can define its type (user story, technical, default), describe it and optionally choose to associate it with a feature, give it a business value and/or make it dependent to another story.
When starting the project, the Sandbox can contain dozens of elements. It is the right place to complete the knowledge about a story. All the participants can contribute and add their comments/notes in the detailed view of the story.
As soon as he thinks that a story is sufficiently detailed, the Product Owner evaluates it. If he thinks it brings value, it accepts it as a story, which moves it in the backlog of the Backlogs view. You can accept a story in its descriptive panel by clicking on the Accept button, or directly on the post-it if you click on “…”.
A little trick: if you want to accept/select/delete several stories all at once, you can activate the bulk selection by clicking on the dedicated button in the toolbar below your avatar.
The Product Owner defines priorities by moving the post-its. The highest priority is at the top left of the view. Thanks to the Rank button you can also automatically sort your stories by type, effort, feature, date of creation, etc…
The team estimates the stories, generally through a planning poker session. The estimations are entered by a team member or by the ScrumMaster, by clicking on the ‘?’ on the Post-it or selecting it in the details panel.
By default, the evaluation can be done according to the Fibonacci suite. This can be changed by modifying the practices of your project. To do so, go to project’s dropdown menu (click on the iceScrum logo, in the top left of your screen) and click on Settings and then on Practices.
Advanced practices: You can estimate your stories by comparing them with your other estimated stories. To do so, click on the button next to the Value and/or Effort fields. A modal window will appear instantly with the stories you previously estimated and will give you an overview of those stories. This overview will remind you of the previous experiences and help you make the right estimation.
Release planning consists in the association of stories from the backlog to sprints of the release. Only estimated stories are candidate for planning and the sprints must also be created. It will be possible later to changes the association, e.g. by moving a story from one sprint to another one.
Once sprints of the release are created and the backlog is estimated and prioritized, the planning can be done. With iceScrum, the release planning can be done manually or automatically (iceScrum takes velocity and priority into account for automatic planning). Since velocity is not measured at the beginning, it is better to do a manual planning.
An easy way to plan a story manually is to open the Planning view and click on “…” and then on Plan, a new panel displaying all the estimated stories will appear and you can select all the ones you want to plan and then click on the Plan button. The list of stories appearing in the Planning view is the ordered list of estimated elements from the backlog.
To help you getting started, the first release is automatically started.
To plan your stories in a new sprint, go to the Planning view and click on Plan. A modal will appear, displaying all the estimated stories you have in your backlog. Select the stories by clicking on each one you want to go in your sprint and then click on Plan again. Now you will see your planned stories when you go on the Task board view.
The Task board view displays a board with coloured margins representing the planned stories and post-its representing the tasks.
During sprint planning meetings, during which the team members identify the tasks, it is possible to create recurrent tasks which can be copied over the sprints and urgent tasks that doesn’t belong to a story.
When all the tasks are created, with their eventual remaining time and a person designated as responsible for it, the sprint can be activated to materialize the commitment agreed in the meeting.
Congratulations, you are now ready to activate your sprint! You can do it from the Planning view:
Or from the Task board view:
Be careful, once a sprint is activated this cannot be undone!
Your team members will then be able to update the status of their tasks by dragging them to the column In Progress and Done and update their remaining time. Of course, other tasks can be created if necessary.
One last tip before letting you start: In all the views of iceScrum V7 you have many buttons to click on, some of them are blue. When the blue button is next to the “…” sign clicking on it will lead you to the next logical action, depending on your context, contained in the list of actions if you had click on “…”. For example if you go to the Sandbox a blue button will propose you to create a new story. Then if you click on this newly created story a blue button will propose you to accept it which is the logical next move for a freshly created story. And once accepted the same blue button will propose you to estimate it, etc… So keep it in mind, the blue button always helps!
|Virtual Task Board|
|Scrum Item Breakdown|
|Indicator & reporting|
|Switch user in task board|
|Web Services API (REST)|
|IntelliJ IDEA Plugin|
|Jenkins / CI integration|
|Embeddable HTML Widget|
|Create Items from Email|
|LDAP/AD User Directory||*|
|Bug Trackers (JIRA, Mantis, Bugzilla, Redmine, TRAC)|