Scrumboard teams management

Scrumboard teams management


Scrumboard teams management

How to easily reorient effort among products

Ok fine, your team is agile. So you can cope with changes in the priority of one product thanks to Scrum.

But how to cope with priority shifts among different products? With turnover?

The answer is simple: flexible team members assignment

It is not perfect. It should be avoided if possible. It reduces velocity. It is the real wold.

How easily can you do it? Let's find out with teams management

How does it work?

1 Designate a tribe leader

We introduce the notion of tribe. It simply represents the group of people by which a set of products is implemented. It is then the unit in which (re)assignments are flexible.

A tribe is managed by a tribe leader that will typically define priorities among products and propose and execute team members reassignment.

2 Define the teams

The tribe leader affects team members to different teams. A team is associated to one product.

3 Update the tribe setup when required

Priority shifts, team members expectations, new arrivals, departures, many things can happen. It needs to be reflected as soon as possible in the Scrum teams to maintain predictability. The tribe leader will manage this complexity easily.

Scrumboard … Sprint board !

Scrumboard … Sprint board !


Scrumboard ... Sprint board

How to provide visibility on your on-going activities

The sprint backlog is important: it is where the team life stands.

If your team is not collocated it is not important, it is vital.

You need it to be clear, collaborative, persistent, customizable yet story focused.

That is the job of the sprint board.

How does it work?

1 Start a sprint

By running a sprint planning session until the end, you will define what your sprint contains.

2 The board is there

A Sprint has been created with the stories that you have selected. It can be visualized in its Sprint board right away.

3 Update the board at daily standup

You can assign one or several members to a story (we like pair programming), update remaining effort and move from column to column. 

4 Create a status report

When everyone has done his updates, save the report. It is helpful to checkout the burndown and to communicate to stakeholders. All reports are saved, so you can replay the sprint afterwards, typically during the retrospective.

Scrumboard Request management

Scrumboard Request management


Scrumboard Request management

How to distinguish stakeholders' demands and stories

Consistency is key to product adoption.

Users are surrounded with interfaces and only the most consistent, appealing, intuitive and efficient products stay alive.

What is required to reach it?

What you don't need is to flood your backlog with the ideas of your stakeholders, usually in form of solution and potentially orthogonal to your product.

What you need is focus and creativity to identify the underlying problem and then correctly integrate a functional solution into a new feature that will end up in a valuable use case for your users.

What you need is to keep control of what your product does and how it does it.

How? Give a try to request management

How does it work?

1 Only the Product Owner can create stories

That is the first thing: the Product Owner owns the product backlog. So it is his job to define the aspects of the stories and how it answers to a given need.

2 The stakeholders create requests

Requests management allows any of your stakeholders to create demands on your product by logging a request.

3 The Product Owner analyzes the request

That is the whole point: the PO figures out the fundamental need underlying the request and design the most adapted solution in terms of story.

4 The Product Owner manages the request

The answer to a request can be to reject it if it is not a fit in the product, to create one or several stories to implement it or even to link stories already present in the backlog.

5 The requester follows the implementation

Once stories are created, the lifecycle of the request is aligned with the stories linked to it: it is automatically set to "done" when all stories are done.

Scrumboard automatic roadmap

Scrumboard automatic roadmap


Scrumboard automatic roadmap

How to provide visibility on your roadmap

Can you provide a roadmap for your product? That is a question that we get a lot when introducing agile. As a customer, a manager, a sales person, you are certainly interested in target dates.

In Scrum there is no guarantee that a given feature will be released at a given date.  We always welcome changes in the product backlog to accomodate priority shift. But at any moment you can provide the current target date of a given story.

This is the purpose of the automatic roadmap feature.

This is computed and maintained automatically !

See it in video

How does it work?

1 Roughly estimate the items in your backlog

When inserting the story in the backlog, the PO provides a rough sizing that will be used only for long term plan. He/She may ask the team (or anyone else) for help in such exercise. Anyway the PO is the owner of this estimation: it is not to be confused with the estimation that is used in Sprint planning and that has to be defined collectively by the team.

All done! There is no next step

If you respect this constraint, Scrumboard will automatically maintain your full backlog planned and live updated with any change.

It will as well provide target dates to the requests of your customers.

What can impact the planning of a story?

The product backlog updates

Obviously, if you change the priority of the stories, or insert new ones, the previously computed dates will change. And that is actually the goal, because it delivers greater value

The duration of the sprints

You can change this value in the product configuration

The team velocity factor

This value is used to help converge the team velocity and estimations to reach predictability faster. You can change this value in the product configuration. You can find more details in the team velocity management feature.

The team size

If your team changes in size, it will impact the team planned velocity and alter the planning. See more on this in velocity management.

Scrumboard velocity management

Scrumboard velocity management


Scrumboard Velocity Management

How to reach predictability

Predictability is what your customer value the most

Sustainable pace is what your team value the most.

Good news: they both rely on finding the correct tempo.

How? Look at velocity management

How does it work?

1 Run a Sprint

By default the sizing is expressed in ideal days in Scrumboard and team velocity is 100%. So if you are 7 team members working on 3 weeks sprints, you can cope with 105 ideal days.


2 Update the team velocity factor

At the end of the first sprint, typically during the retrospective, checkout how well you perform compared to what was planned and adapt the team velocity factor accordingly in the configuration.

Alternatively, you can alter the way sizings are done. Both ways are OK, yet team velocity change is more intuitive than to try to alter how the team does its estimations.

3 Iterate and converge

Continue to reassess your real velocity and fine tune team velocity factor 

4 Cope with team changes

While it is a good idea to keep the team as it is in the long run to benefit from its converged predictability, life happens.

People move for many reasons. 

An arrival or a departure in the team alters right away the team velocity: we apply the current team velocity factor to the new resource level.

5 Cope with part time

Scrum asks for full time team members, and yes you should do it as much as possible.

Yet again, life happens and we know that in real life, it can occur.

To cope with it, you may not wait for a sprint or two to realign team velocity, so you can use availability (in team member edition) to reflect this.