TFS & PivotalTracker

When we started 4 years ago using Scrum the PO decided to use PivotalTracker to manage the Backlog and the roadmap.

We also had a physical board for the current sprint, but we found very useful to have the virtual one.

office-wallMy “wall” in Turin a couple of years ago, before we moved in a newer room.

Continue reading


Matter of Metrics and Improvements (how it started!)

I hate the metrics.
Really, I hate them.

Generally speaking now I hate any file excel in which I should put a lot of numbers.
Because years ago the 99% of the time that I took that metrics I didn’t know what to do with that numbers, I didn’t know when to use it, I didn’t know how to read it in order to be useful.
In my past experiences the metrics that I had taken were never useful to improve a workflow or avoid the same mistake.
Gathering those metrics had been only a colossal loss of time.

Continue reading

A London-Turin retrospective

sherlock Prologue (suggested theme music for this post here)

At the end of June I moved to begin a secondment for one year in our London office. One of the purpose of the secondment is to help to implement a software developed by my team in Turin.

So I temporarily dropped my Scrum Master role and I became Tech Leader of a new project in UK that had to use the new software: we went live at the end of July, but a lot of things happened even if the launch has been a success.

Continue reading

About User Stories

User Stories are very central in any Agile methodology and very often are the first cause of a failure (or success) in a software development.
Speaking about User Stories with a colleague in London, I noticed like the topic is every time (no matter the Country nor the person) much more complicated than expected, mostly if you are new on the field.

If you speak about User Stories is quite simple that, at the question “How a User Story should be?”, your answer will probably be an emphatic “INVEST!”
I agree, but I’ve noticed that to apply the INVEST approach is much more hard than expected. The theory is pretty clear, but somehow not so much clear how to put it in a User Story.
Continue reading

Definition of Done

I think it is a must in an agile team.
The Definition Of Done is a good starting point for a new team or a new software that a team should begin.

In fact, from my point of view a DOD is not just related to a team, but to a team bound to a specific project.
In theory every agile team should have only a software (or a part of it) to deal with, but my world is not so well compartmentalized and it happened that my team had to work on multiple software even if, luckily, not often at the same time.

In any case the point is: hardly a DOD used for a software was good enough for another software.

Continue reading

No problems means Problems

Deal every day with problems is tiresome, sometimes frustrating (click here to have a taste of it!), but for me the real problems start when I don’t have any problem.
The sprint retrospective is a perfect time and place to deal with problems, but what if the sprint went well and no one has to complain?
Or what if more sprints went well in a row?

Well, when a new team starts there are a lot of problems, but after few months it is not so strange to have a period where everything goes in the right way: your software is growing well, your Stakeholder are enough satisfied and the team found the right rhythm.

If you have this kind of period there’s a chance that your retrospective become useless, boring and, like it happened to me, you begin to ask to yourself: and now? Continue reading