Loading ...
Sorry, an error occurred while loading the content.

55013Re: Scrum Implementation for Re-Engineering projects

Expand Messages
  • animgpt
    Apr 13, 2012
      Thanks for quick responses...

      Let me provide some more insight into the project. This project has multiple data loaders written in PL/SQL. The data extraction, transformation, and loading logic is embedded into each loader's PL/SQL code. Since there isn't any documentation available, code maintainability is a huge issue. Business objective is to make code more maintainable and use some latest ETL tool to do the job easily.

      Product backlog can be formed by listing all the loaders and business also can prioritize the backlog. First problem is that the backlog in this case won't have user stories, it would have epics as each loader had huge functional code.

      Next problem is with estimating each loader and the storeis withi it in terms of story points. Without understanding the code it is not possible for the team to identify stories and estimate them for each data loader. I could put couple of initial sprints for code analysis and writing user stories/BRDs for each loader, but the problem is that these sprints won't have any functional deliverables. Moreover once the team starts with code analysis, they can simultaneously translate the code to a new technology as well. The user story/BRD creation in this case is just for the matter of producing some documentation as there is no new functionality getting added.

      What is the best way to implement scrum in such a scenario?

      --- In scrumdevelopment@yahoogroups.com, "Steve" <steve@...> wrote:
      > Let me add my support to Adrians suggestion of getting a Product Backlog created. This needs to be done with thte stakeholders organised by a Product Owner; as the PM/Scrum Master you should not do this yourself!
      > Once a PB has been created you can investigate the code in depth for the top one or two items to give the team some idea of the complexity of the task and then use Planning Poker to estimate the PB.
      > It may be that these initial investigations reveal that estimation of the rest of the PB would be fruitless and if so, I would suggest using a more Lean/Kanban approach to begin with, maybe moving toward a more Scrum approach as the team gains experience.
      > Of course, I assume that the new technology has been chosen and that some sort of business case has been prepared to justify this activity.
      > Let us all know how you get on
      > --- In scrumdevelopment@yahoogroups.com, "animgpt" <animgpt@> wrote:
      > >
      > > I am looking for information on implementing scrum on re-engineering projects.
      > > My project has a legacy code without any documentation. Code needs to be read, understood, and recoded in a newer technology. I don't have a product backlog, no idea of estimate for each module, etc. unless code is digged into.
      > > I am finding lots of difficulties in implementing scrum on such a project.
      > > Anyone who has used scrum on similar project, please suggest.
      > >
    • Show all 8 messages in this topic