Skip to main content

Pending Changes - Sprint Item Status?

Last post 06:41 pm December 17, 2019 by Ian Mitchell
6 replies
10:12 pm December 16, 2019

Hi everyone,

 

I'm on a team that has a mix of development work, and infrastructure support, and there's been some questions about the correct status for items in our sprints. Specifically we're having trouble with addressing vulnerability remediation tasks that need to be filed as changes as they impact our production network. The filing of the change means that we have ~3 days where the work is defined, but not actionable while we wait for CAB approval, etc., so they question is whether or not we put them in Blocked status during that 3-day window.

Our definition of done is minimally functional and ready to be deployed for testing, but we do not have a true duplicate of our production environment so many of these changes aren't proven to work for various reasons, but more importantly aren't proven to satisfy the security folks' scanning. I'd say that if we had surface to test the fix, and confirm it satisfies the scan, it would be moved to done, but for the reasons above I don't that's appropriate. I also don't feel like Ready in the Sprint backlog is appropriate since there's no work to be done since we're pending the change implementation window. In progress seems wrong since nobody is committing any resources presently. So we've landed on Blocked, which also feel wrong, but maybe the least wrong?

I'm pretty new to scrum, and feel like I'm in need of education on this one. Does anyone have any suggestions, or can point me to some documentation I might have missed along my journey of scrum knowledge?

 

Thanks in advance for your notes,

-Kevin


10:51 pm December 16, 2019

What is being done to bring CAB approval and security competencies within the Development Team so it becomes adequately cross-functional?


10:52 pm December 16, 2019

A few things stand out to me.

First, why are you planning work for a Sprint that isn't ready to start right away? I understand the need for change control and approval, but is there a reason why the approval to make a requested or desired change can't come before a Sprint begins? I believe that this would give you more predictability in your work - if you bring in more planned and approved work, you can be sure that you can actually efficiently start work without unexpected delays from outside of the Scrum Team.

Second, why don't you have a "true duplicate" of your production environment? I can see this being extremely beneficial. Your team can execute the work, test the work, and give confidence to the various change control processes that, when rolled out to production that things will work. You can further decouple your Scrum Team's execution from the change control process and start work that hasn't been approved yet, verify and validate that your understanding of the problem is correct and the intended solutions will resolve the problems, and then roll it out to production after satisfying the change control process.

I don't think that problems that you are facing are problems with Scrum, but your environment and the broader organizational processes. My recommendation are to solve those two points that I mentioned above. First, establish a true copy of production that you can use to develop and test your solution, giving a higher level of confidence to stakeholders. Second, be able to plan based on work that is already approved and ready to go - and this can be easier if you can perform better testing and feedback loops prior to rolling it out in production.


02:18 pm December 17, 2019

Thomas, 

The bulk of the actual "work" part for the security items is really investigating to see if the item is false positive, and researching the options for hardening the CI in question. The work that's being performed in the change is usually something simple like updating a GPO, or checking a box somewhere. 

So its normally ~2 hours research ==> 3 days pending CAB ==> 5 minutes configuring

We'd love a test environment and are actively pursuing that, but until we have that we have to work in the world we live in. Most of our work can be tested in the test environment we have, but some of our border elements are more difficult to duplicate. 

 

Ian,

I don't know if the CAB folks can give us a resource to achieve cross functionality. I think the closest we could come would be achieving a standard change template that might allow us to fast track some of our changes, but I don't think they'd go for that of our use case is as broad as it is for these security items. Is this something you've seen on other teams?


04:06 pm December 17, 2019

I'm going to give the age old response of "do what makes sense for your team".  There is nothing in Scrum that says anything about what statuses to use on a Sprint Backlog Item during the Sprint.  Workflow is entirely up to the people doing the work to decide.  We could all give you some opinions but in the end, the only answer is "what makes sense for your team".  

I'll give you my opinion.  Blocked is not accurate.  You have an identified workflow and it seems to me that the CAB period of that workflow is review not blockage. My definition of a blockage is something preventing you from doing something that you know needs to be done. Since the CAB approval is required before you can make the change, the change is not a "known".  At that point is a "suggested" change. So I'd suggest something like Review or Pending Approval because it seems more accurate to me. 

So its normally ~2 hours research ==> 3 days pending CAB ==> 5 minutes configuring

The way I read that statement is "2 hours of discovery==> 3 days pending stakeholder feedback ==> 5 minutes work".  So I'd suggest that it be done outside of the Product/Spring Backlogs and when the work is finally identified as being needed, you just make the change.  Is it really worth the overhead of tracking it as a Sprint Backlog Item?  Do these changes have any impact on the potentially releasable increment of product functionality that your Sprint Goal is leading you to create? You can still use a ticket in your tracking system to have documentation. But unless it is truly a change made in order to deliver value to your stakeholders I'd question whether this is a Product Backlog item.


04:18 pm December 17, 2019

The bulk of the actual "work" part for the security items is really investigating to see if the item is false positive, and researching the options for hardening the CI in question. The work that's being performed in the change is usually something simple like updating a GPO, or checking a box somewhere. 

So its normally ~2 hours research ==> 3 days pending CAB ==> 5 minutes configuring

We'd love a test environment and are actively pursuing that, but until we have that we have to work in the world we live in. Most of our work can be tested in the test environment we have, but some of our border elements are more difficult to duplicate. 

What you describe as the bulk of the "actual work" strikes me as more closely aligned with Product Backlog Refinement. In Scrum, you would allocate ~10% (but there's no defined timebox or maximum time to spend in refinement) of your Development Team's actual capacity for each Sprint to this type of work.

If what you describe is that most of the work is research and then a trivial change, then I'd question whether Scrum is appropriate for your type of work. I do still see the benefits in having one or more test environments that mimic production to give you the opportunity to test your changes and demonstrate that they are correct, but it seems like tracking this type of work as a Product Backlog Item and creating and managing Sprint Backlogs is adding unnecessary overhead.


06:41 pm December 17, 2019

I don't know if the CAB folks can give us a resource to achieve cross functionality. I think the closest we could come would be achieving a standard change template that might allow us to fast track some of our changes, but I don't think they'd go for that of our use case is as broad as it is for these security items.

What else might be done to bring CAB approval and security competencies within the Development Team so it becomes adequately cross-functional? What about having security champions on the team for example, and observing a release-quality Definition of Done?

Is this something you've seen on other teams?

I usually only find cross-functional teams and release-quality Definitions of Done where there is sponsorship for deep and pervasive organizational change.


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.