Externals in the Nexus integration team and their relationship with the Product Backlog
Hi !!
Reading "Nexus framework" book. In the sixth chapter I have read one thing that is sounding in my head continuously.
Context is with external collaborators integrated occasionally in the Nexus integration team.
Their “outside” work would not be represented on the Product Backlog because it does not benefit the Product.
Really? If one external professional improves the product because team has not that skill I guess is an improvement in the product and it should be in the PB.
Maybe I am in wrong, could you help me in this doubt?
Thank you!
The definition of the Product Backlog from the Scrum Guide applies:
The Product Backlog is an ordered list of everything that is known to be needed in the product. It is the single source of requirements for any changes to be made to the product.
If it's not a source of requirements for changes to the product, it doesn't belong in the Product Backlog. However, there may be other things of interest that can be made visible, estimated, prioritized, and tracked. Perhaps you can use the same tools that you use for your Product Backlog, but strictly speaking, they aren't part of the Product Backlog.
The other thing is that the Nexus Integration Team, is not a Scrum Team. The concern is that having this "outside" work added to the backlog is that the NIT tends to take on the mentality of a Scrum Team because they would be taking work from the backlog and completing it.
Keep in mind, this does not apply to everything the NIT does. If the NIT does work towards integrating the increment and/or work to make it possible for better processes, like CI/CD; that would likely go on the Product Backlog as it allows for more transparency.
Really? If one external professional improves the product because team has not that skill I guess is an improvement in the product and it should be in the PB.
If that improvement adds to the work remaining for the Product, it ought to be accounted for on the Product Backlog, which could just mean increasing the estimate of relevant items. It isn't necessarily going to be represented on the Product Backlog as a discrete item in its own right. Doing so would only make sense if the Product Owner recognized its value to the Product and could reasonably manage and order it.