Documentación Esta documentación se aplica solo a iceScrum v7.
Para el antiguo iceScrum R6, lea la documentación o migrate.
Find how iceScrum helps you manage your product development, depending on your context.
Definitions
The agile project management field comes with a lot of terms that often have different definitions. The point of this section is to provide our definitions, which are not universal but should help build a shared understanding.
Backlog
When used in singular form, it refers to «Product backlog». It is an ordered list of things that the team may produce: stories. This list and its content evolve as the business and technical knowledge grows. The stories with the highest priority are taken from the backlog and planned into the next sprint where the team will integrate them into the product.
Feature
A feature is a service or functionality that is part of the product and provides value to end users. It is high-level and can be divided into stories. Read more about features in the dedicated documentation.
Feature team
A feature team is a team as we defined plus additional characteristics. When a product is too big to be developed by only one team then it is developed by several teams. When the work is split across them as features they become feature teams. This is opposed to component teams to which work is attributed depending on what part of the architecture is affected, excluding them from our definition of a team.
Portfolio
A portfolio refers to the corresponding iceScrum workspace. It helps organize the repartition of features into feature teams so that’s where high-level business decisions are taken when applying large-scale Scrum. It is used by business owners and stakeholders. Read more in the dedicated documentation.
Depending on your context, an iceScrum portfolio may or may not relate to the outside world concept.
Product
A product is something that provides values to an audience, or in other words, something that benefits to a market. A product can be composed of other products if they fit the definition. Agile methodologies were initially designed to improve software project management so the term mainly refers to a software product.
Project
In the context of iceScrum, a project just refers to the corresponding iceScrum workspace. A project is a workspace for one team to deliver product increments.
A project has Product Owners and optionally stakeholders. Read more about these roles in the dedicated documentation. A project is associated with one team. It hosts a backlog that contains ordered stories, a schedule that consists of releases and sprints, and a task board that helps manage the work achieved by the team during a sprint.
Depending on your context, an iceScrum project may or may not relate to the outside world concept; organizing product development as «projects» is a whole separate discussion and we don’t aim to argue about that here.
Release
A release is a timebox that consists of several sprints and usually lasts from 2 to 6 months. It is associated with a vision of the product that could realistically be produced in this time. The vision not a fixed commitment, it is a direction given to the team that evolves as business knowledge evolves. While a release may be associated with the action of «releasing» or «deploy» a version of the product, it is advised to do that more often than once per release.
Sprint
A sprint is a timebox that usually lasts from 1 to 6 weeks, during which the team works on a set of stories resulting in a potentially shippable product increment. The sprint has a goal, usually describing this product increment. While the result must be potentially shippable, depending on your context you may want to ship several versions of a product during a sprint or on the contrary wait several sprints to do so (usually the more often the better).
Story
A story is a product backlog item (often called PBI) that can either bring value to end users or to the team. Stories are usually a subdivision of features and are less valuable than features but much finer-grain so they are more manageable. In iceScrum there are three types of stories: user stories, defect stories (or bugs) and technical stories (often called spikes). Read more about stories and their workflow in the dedicated documentation.
Team
Team is a short-and for «agile team» which is a small, long-lived, self-organized, cross-functional and cross-component team which objective is to produce end-to-end valuable features increments to a product. Each part of this definition would deserve its own explanation and if you have any doubt about their meaning, we mainly agree with the definitions you will find online agile communities and blogs. An iceScrum team consists of Team Members and ScrumMasters. Read more about these roles in the dedicated documentation. For practical reasons, an iceScrum team can be associated with 0, 1 or many projects. However, at a given time, a team should is expected to work on one project.
Timebox
«A timebox is a previously agreed period of time during which a person or a team works steadily towards completion of some goal»
Workspace
A workspace is an iceScrum concept. Workspaces are scopes in which a user or a group of people can organize their work in iceScrum. There are currently three workspaces, one individual: the user personal home, and two collaborative: the project and the portfolio.
Manage your product development with iceScrum
There are good chances that your organization does not fit the ideal agile / Scrum team as described above. Instead of looking for a methodology that fits your current organization, we advise that you consider changing your organization so it better fits the context expected by Scrum.
Changing a whole organization to please a method may seem overkill. However, the criteria you need to meet to come close to having ideal Scrum teams will likely become enablers for your organization, not hindrances. They will help foster innovation, reduce friction, decrease time to market, and reduce costs. Enabling the use of Scrum will only be a nice side-effect of having transformed into an agile organization.
You will find below the solutions we advise depending on your context, and how you can use iceScrum to implement them.
a. Very small team
Less than 2 full-time developers.
Solution
The Scrum methodology is probably partially applicable, but a very small sized team is likely to be unable to provide stories at a steady rate through sprints, thus failing too fully meet the Scrum expectations. Maintain regular inspection and adaptation through reviews and retrospectives.
iceScrum implementation
Keep things as light as possible: one project, one team. As iceScrum is meant to provide features adapted to a full-blown team, you may find yourself using only a small part of its capabilities. For example, you may consider creating a very long sprint into a very long release, disabling estimates and managing stories in a Kanban style. Introduce new practices if retrospectives indicate their need.
b. 1 team / 1 product
For a small to medium product.
Solution
You are in the sweet spot: the Scrum methodology is a perfect fit for you.
iceScrum implementation
Create a team and create a project associated with this team and you are ready to go!
c. 1 team / many products
Solution
One of the pillars of Scrum is the ordered backlog. Its strength is that its order alone «decides» what the team is doing next. If you split the team work across several backlogs, there is no way to decide how to pick the next items. Thus, it may be wise to organize the work around the team itself rather than around each product, thus dealing with only one team backlog. There is however a drawback to this approach: there can be only one Product Owner for the several products you manage. Indeed, the backlog order will mix stories for different products and the person who will decide this order must have business knowledge for the products. In this case, the result of sprints is not one but several product increments.
iceScrum implementation
Create a team and create a project that will help organize its work. Then, choose a tag for each product and assign it to each feature and story that is associated to it. Tags are displayed on virtual post-its, thus allowing knowing the product at a glance. Tags also allow filtering (through custom backlogs and contexts). A drawback of this implementation is that it will prevent you to expose the whole project to your stakeholders, as they may see informations about the products of other customers.
d. 1 big team / 1 big product
Solution 1
If the team is able to be agile despite being large, which is not found often, then you can refer to case b. If however your team lack agility, it would not be wise to try scaling agile up to meet your team. Instead, you should consider scaling your team down as suggested in solutions 2 and 3.
Solution 2
Just reducing the team size may lead to significant improvements: less complexity, more alignment, improved collaboration, increased velocity, reduced costs. As a result, you may be back in case d again so you can apply its solutions again, or in case b.
Solution 3
Split the team, which leads you to case e.
iceScrum implementation
Follow the implementation advised in the case you end up being after applying the solution provided above.
e. Many teams / 1 big product
Solution 1
First you should consider if your product can itself be decomposed as products, meaning that they have a market individually. If so, your have several products (which happen to be sub-products of a bigger one) and one team for each product. You are back to case b. It is probably relevant to make the Product Owners meet regularly, just as a regular Product Owner must meet their stakeholders in order to update the product vision. The advantage of this approach is that scaling agile boils down to the sum of regular agile teams, which problems are well studied and addressed by agile methodologies.
iceScrum implementation 1
Follow the implementation advised in the case b: each sub-product is managed with one team in one iceScrum project. You can give the Product Owner of every project the role Stakeholder on the other projects.
Solution 2
If and only if solution 1 can’t work then you should split the team. A common (but not so wise) way to do so consists in creating component teams. e.g. one for the backend, one for the mobile app, one for a web interface, etc. To deliver a single feature, all the teams have to their part, there are lots of dependencies and handoffs between them so they need to be coordinated, adding a significant overhead and risk. We rather recommend splitting the team into feature teams.
Feature teams only answer part of the problem. Now that you have several teams, how do they collaborate on the product development? The common wisdom among experts of the field is that feature teams should have synchronized releases and sprints in order to facilitate communication and logistics.
iceScrum implementation 2
Create a portfolio to aggregate your projects, with one project per feature team. Synchronize releases and sprints across the projects. iceScrum will tell you if your projects are not synchronized and will soon provide a way to automatize the synchronization. Read more in the dedicated documentation.
