Inclusion of Documentation work as Story in Sprints

Sandip - If that work is needed for all of your Product Backlog items in general terms, then it would be made transparent in the Definition of Done. If those steps are unique to a Product Backlog item, it could be referred to in acceptance criteria.

The Definition of Done can be used by the Developers when deciding and capturing the effort.

I'd agree with Chris that the best place to put this work is either in the Definition of Done for things that are globally true or in the Product Backlog Item itself for things that are particular to a specific Product Backlog Item. I'd also suggest that you may have some references to this work in your Definition of Done, such as "update OQ scripts" and "execute IQ", but you may also reference more specific details on what that means for a particular Product Backlog Item within that Product Backlog Item. The approach of acceptance criteria is one good option for this.

I do have a few additional suggestions, though, but there's not enough information given to know how useful they will be to you:

• I recommend not referring to people as "resources". Johanna Rothman, among many others, has a good article on this. It can be demotivating and even dehumanizing to treat people as resources.
• With the terms like OQ and IQ, I'm guessing your in a regulated environment, perhaps medical devices or pharmaceuticals. You also mention a specific person needing to do this work. If you need independence, I'd consider moving qualification outside of the Scrum Team. If you don't need independence, I'd want to know why one person in particular needs to do this rather than sharing the work across all members of the team.
• Consider automation. Automating tests will make them more repeatable and allow them to be run faster, more frequently, and with less of a chance for human error. This shortens the feedback loop for the team.

which needs to be done by one of the scrum team members (devops).

Why by only one of them? I'd suggest that your challenge is not one of story writing, but of encouraging a shared accountability for team commitments.

Please let me know what is the proper scrum way of having these activities in form of a story

Simple answer is that there is no such thing as a "proper scrum way" especially when it comes to stories/user stories.  User Stories are not a requirement in Scrum.  The section of the Scrum Guide that describes the Product Backlog only says that 

The Product Backlog is an emergent, ordered list of what is needed to improve the product.

and 

Product Backlog refinement is the act of breaking down and further defining Product Backlog items into smaller more precise items. This is an ongoing activity to add details, such as a description, order, and size. Attributes often vary with the domain of work.

So if you need to capture this work as a Product Backlog Item, capture any relevant information in some manner and make sure it is refined as such to be completed within a Sprint. 

I agree with the others that this could easily be a part of the Definition of Done if it is required on every increment of value or as Acceptance Criteria listed in the Product Backlog Item if specific to individual pieces of work. In truth this sounds more like a sub-task needed to complete the Product Backlog Item and could even be a column on your board. 

I fully support the suggestion of automating these tests if possible.  That will eliminate the need for a specific individual to perform the work and make them easier to repeat. 

Thanks every one. I am trying to explain the scenario in a little more detail fashion. These IQ execution was never part of the devops scope initially. Hence the PB items are not mapped to different scripts. Now the customer want help from us in this process. Hence we need to dedicate one resource for this test script writing. There was no clarity in the writing of the scripts when PB  refinement and SB refinement was going on. Hence we landed in this situation.

Now for this particular scenario, how can we handle this. Should we create a story for writing the OQ scripts and have that assigned. 

Thanks for the above suggestions, we will take this for future planning and update the Acceptance criteria accordingly.

Hi Thomas & All- Please note we had the other associates assigned to some other critical stories..we are also considering the possibility of automation test case in near future.

Regards

Sandip

Sandip - Yes, all future work needed should be made transparent and added to the Product Backlog. Scrum doesn't require Product Backlog items to be described in a user story format, the Scrum Team can use whatever format or template that works best for them.

There was no clarity in the writing of the scripts when PB  refinement and SB refinement was going on. Hence we landed in this situation.

Many would consider this technical debt. Regardless get it on the Product Backlog and pay it back.

I'd agree with Chris - this seems like a case of technical debt. It sounds like the team needs to change its Definition of Done to include this new scope. For future work, you can include it in how you create, split, and size Product Backlog Items, but you still need to address the previously-Done Product Backlog Items that don't have this work done.

I'm not sure exactly what you mean by "story", but this work should be captured on the Product Backlog for sure. If, by "story", you mean a very specific format or structure, I find that too much focus on structure detracts from capturing the work in a way that is understood by all of the relevant stakeholders. Focus on ways to divide up the work in a way that it can be ordered among everything else and completed over time to pay back the technical debt and close the gaps that exist.

Agree with @Chris Belknap and @Thomas Owens for the most part.  But what isn't clear to me is whether this is a one time situation or if this will become standard going forward.  Also not clear is if this product is being built for one specific customer or if it is for mass use. 

I mention those things because it would influence my suggestions. If this is a one time situation then I'd add items to the Product Backlog but not update the Definition of Done.  The goal is to capture the work and plan it accordingly in a Sprint.  However if this does become a standard going forward, I'd add items to the Product Backlog for this one occurrence so that it can be planned into a Sprint and update the Definition of Done to include the requirements going forward so that Product Backlog Items are not explicitly needed every time. 

There would be similar considerations if this was a single customer product vs mass usage. Do what makes it apparent that the work needs to be done in a way that involves the least amount of work to track it.