Skip to main content

Tool recommandation PO

Last post 08:12 pm October 19, 2019 by Thomas Owens
5 replies
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 :-)

 

 



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?


By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your Scrum.org member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use

Scrum.org may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Scrum.org Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by Scrum.org may have their access revoked at any time, without warning. Scrum.org may, but is not obliged to, monitor submissions.