Split PBI in separate items for development and deploy?
Hi guys,
Our PBI's currently contain the work for the actual development and deployment (to Dev, to Staging and to Prod). However in some cases we are not able to do all the deployment steps in one Sprint. Sometimes deployment steps are blocked because other PBI's need to be deployed first.
This results in some PBI's not getting to Done by the end of the Sprint, while the actual development is already done and sometimes the PBI already reached the Staging environment, so only one action left.
Currently we are thinking about splitting each PBI up into 4 items: Develop the feature, deploy to DEV, deploy to Staging and deploy to Prod. That way we will be able to get items to Done and we can decide on leaving some deployment steps out of the sprint. Downside would be that if you have 10 features you need to create 40 items.
Another though that we had was to create 3 deploy items for each sprint. Deploy to DEV, deploy to staging and deploy to Prod. In each of the items you link the PBIs you want to have in the specific environment by the end of the sprint. In that way you can move the features from one to another if they are ready to go to the next environment.
I am curious how others deal with this situations? Are there any best practices?
Thanks in advance!
Vincent
Your suggestions amount to introducing each waterfall phase as a separate PBI. Nothing very "Agile" about that approach, unfortunately.
The Scrum guide is very explicit about this:
"The purpose of each Sprint is to deliver Increments of potentially releasable functionality... This Increment is useable, so a Product Owner may choose to immediately release it."
I came across a very good quote today that I believe sums up your situation:
"Doing Scrum won’t make you agile, but it will surely show you where you are not."
I believe you are identifying where your organization needs to improve in order to follow Scrum and be Agile. Your resolution should be around changing your organization, and not trying to change Scrum.
Why are team members planning work into a Sprint which they are unlikely to complete, by the end of that time-box, to a standard of release quality?
We put all our production deployment tasks into a seperate story in the sprint, only to make it easier to track the change management documents for each. So if story A has a deployment to production task, it gets put in the Deploy Sprint story so that it can be tracked there.
So far it's worked pretty well in that it's let us track that part of the sprint more effectively.
Admittedly, we're doing more of a Scrumban process, so your mileage may vary.
The work was originally expected to be ready by the end of the sprint (including the release), however because we have duplicate Scrum Teams releasing on the same product we sometimes have to wait until another feature is released. Or sometimes issues occur on the environments that need to be solved first before we can do our deployment.
In terms of scrum, the Item satisfies that we have an increment that we can potentially release. However we have the actual release in our definition of done. So we struggle at that point. Do we need to include it in our Definition of Done, or do we change our definition of done to a "potentially releasable increment" and add actual deployment tickets to our Backlog that we can pick up in the next sprint?
An increment will not be potentially releasable if there is any further work to be done, including deployment. In Scrum release should possible immediately, at the discretion of the Product Owner, and the effort involved in doing so ought to be negligible.
If there are dependencies between teams, then they will need to collaborate in order to integrate their work, and to deliver an end-of-Sprint increment of release quality. My advice is therefore to approach the matter as an integration challenge, not as one of splitting items into the best bits to camouflage the problem. Have a look at the Nexus Guide for ideas regarding how integration might be assured.