Skip to main content

Agile-Scrum Approach to Robotics Process Automation (RPA) Projects

Last post 08:47 pm May 21, 2021 by Ingo Philipp
3 replies
04:51 am December 11, 2019

Hello, I am into RPA projects where we have a team of 7 developers each working on their own set of tasks for Development for their assigned project, that means at a time there are 3-4 projects going on assigned to diffirent developers. 

Is anybody into RPA projects have implemented Agile-Scrum in their organization. Advice would really be helpful.


05:24 pm December 12, 2019

@Manan Bijlani, The info you provided, according to me is a little vague in order to be able to provide a better answer.

Having said that, it appears that you have a group of people doing work vs a team that is focused on delivering iterative and incremental value driven outcomes.

Any specific reason why you are trying to adopt Scrum? For ex: faster feedback, risk reduction, experiments/hypothesis validation etc?

Do you have dedicated team(s) for each of the projects vs projects split across individuals?If no, why not?


07:27 pm December 13, 2019

@Manan Bijlani, I'm using RPA as a test automation tool within a Scrum Team.



The tests that should get automated for Smoke Regression Suites and normal Regression Suites have to fulfill certain criteria to be considered good candidates, namely:

- The test has to be complete

- The test has to be positive: happy path/happy flow and variants

- The test has had to be executed manually minimum once with a positive result

- The test has to have a defined result

So like you see, using RPA or Selenium for test automation isn't the same as using RPA as development tool for the increment.



My personal believe is that it is doable, but not as a pure Scrum project, rather look at Scrumban with Sprints of 1 week or go directly for the Kanban approach.

The most important steps are:

- split the workload into 1 user story = 1 RPA flow = 1 task.

- get Business (PO or Service Request Manager) feedback asap after the realisation of each user story/task, do not wait for a Sprint Review meeting for validating all the delivered RPA flows (Reworking RPA flows is a b****, so don't let them cumulate)

- your "increment" is not one piece of software that gets developed iterative and incremental, it's a collection of standalone RPA flows that can cover totally seperate functionalities

- Depending on your release maturity you can choose to release the seperate RPA Flows continues or group them as an "increment" on well defined time slots.

- communication and learning is important, so consider the Daily Scrum and Sprint Retrospective as mandatory

- I have not enough information on how you choose the candidates for automation, but I don't believe that a standard Sprint Planning and Refinement would be the best approach. May I suggest to experiment with the selection and workload determination process.

- decide for your team if it's still necessary to organise a Sprint Review meeting if the RPA Flows are validated by Business as soon as they have been finished, personally I see this as doing the same work twice, unless other stakeholders have to see the "increment" before release

Hope that this helps.



With kind regards,

René


07:38 pm May 21, 2021

Hi Manan,

this answer might come a little bit late but you might want to check out this paper. In this paper, we outline (1) how and why an RPA CoE adopted Scrum, Kanban, and XP and (2) discuss how they scaled their RPA delivery with Nexus.

Best, Ingo. 


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.