Tool recommandation PO

Last post 08:12 pm October 19, 2019
by Thomas Owens
5 replies
Author
Messages
01:18 pm October 14, 2019

Hi all,

I know my question occurs often here in different kinds. But I did not want to revive old threads.

For the last 3 months I am Product Owner of a small development team in a startup-like company. We use physical boards and burndown charts for our sprints and daily business and I don't want to change this.

In our case this only works for the sprint and for some topics of the next weeks (room space, backlog complexity...). For e.g. a long-term planning, stakeholder reports, or velocity tracking I would like to find a tool that supports me as product owner. At the moment I use a very user-unfriendly Excel sheet with some makros from one of my predecessors. So, basically I am looking for a Product backlog management tool and not  a scrum team tool.

Any recommendations for me? Please keep in mind I don't want to use a sledgehammer for nuts :-)

 

 

06:23 pm October 15, 2019
02:27 am October 16, 2019

In our case this only works for the sprint and for some topics of the next weeks (room space, backlog complexity...)

Why? Why does it fail to work for anything else, including Product Backlog visualization?

11:52 am October 16, 2019

Jira is a tool that many use for sprints, product backlogs, release planning and gives you all the reports you should need... if it doesn't then there is great 3rd party plugins to fill most gaps. 

Some people will bash on Jira but in my experience... it works. 

03:41 pm October 19, 2019

In my place, All what I have now: a whiteboard marker and good discussion. 

08:12 pm October 19, 2019

You mention that you want to keep track of three things - long-term planning, stakeholder reports, and velocity tracking. We can look at these one at a time.

First, you don't need to track velocity. In fact, you shouldn't be tracking velocity. It's not a very stable metric over time. It's highly sensitive to changes in the process as well as the team's growth and development. It's also a measure of output. Instead, you should be focusing on having goals that the team can achieve Sprint after Sprint such that not achieving the goals is a rare event that can be addressed in the retrospective. Overall, focus on the outcomes that are enabled by the team delivering their work.

Next, long-term planning is generally unnecessary. I'd ask you a question - how do you manage your Product Backlog now? That is, before you have your Sprint work in the physical board, how do you manage your Product Backlog and Product Backlog Items? This is your long-term plan. Anything in the backlog is stuff that you've thought about and consider relevant. The items at the top of the backlog are closer in time than items at the bottom. If someone thinks something further down needs to be done first, that can be considered and the team can refine it. But the ordering, dependency mapping, and level of refinement of items in the Product Backlog is the long-term plan.

As for stakeholder reports, I'm not sure what you mean by this. What do these reports look like? What kinds of information do they contain? How are they useful to you and the rest of the Scrum Team?