Back to Forum

Current increments vs known future

Last post 04:30 pm September 25, 2019 by Artur Polit
2 replies
Artur Polit
08:53 am May 15, 2018

Hello,

At the bottom of our Backlog there was an entitiy versioning feature. This was known from the begining as required to the project but the team argued that we should consider it when it will be coming to the top of the backlog "because the backlog may change and we don't work in waterfall". Eventually that leads to huge changes at the end because the "big picture" was not considered.



As we know the Backlog may constantly change regarding the value which we need to provide to our customers. But we also got some things which we certainly would need because they already proven its value or they are a base for a value-adding features.

Another words I met the behaviour that "this code is not needed for current sprint" but it would be 95% needed for the future PBIs and it would be better to prepare now for the known, certain future.



Now I see that I should insist Product Owner to put the versioning to the top of the Backlog on the begining of the project.



I would like to ask how to advocate for:

* preparing in current Sprints for future PBI

* how to order the known certain non-complex things in the Backlog

* generally how to fit Big Picture into work on shippable product increments

Thanks,

Artur

Ian Mitchell
03:52 pm May 15, 2018

It’s up to the Product Owner to decide how to best order the Product Backlog, and no-one should “insist” on a particular ordering or apply undue pressure.

Irrespective of how the Product Owner chooses to order items, do the team believe that Product Backlog refinement is being conducted appropriately, and that their current approach to refinement is fit for purpose?

Artur Polit
12:47 pm September 25, 2019

Hi Ian, thanks for your answer. 



After some time it turned out that the problem was in not using thin vertical slices in PBI. So we were developing the data ingress not thinking about how that data would be read. If that would be defined as Store and query Item Basic Properties and Store and query Item Advanced Properties then we would have a complete image (in thin slices) which would allow to select a proven solution for whole slice. Rather than implementing the naive solution for data storage and hoping that it would need huge refactors allow effective query later.

 

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.