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

Re: Scrum Implementation for Re-Engineering projects

Expand Messages
  • animgpt
    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,
    Message 1 of 8 , Apr 13, 2012
    • 0 Attachment
      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.
      > >
      >
    • Steve
      Hi A problem with Scrum is that it starts with a Product Backlog; it would then suggest that you cannot do Scrum if you cannot get a PB! However, may I
      Message 2 of 8 , May 8, 2012
      • 0 Attachment
        Hi

        A 'problem' with Scrum is that it starts with a Product Backlog; it would then suggest that you cannot do Scrum if you cannot get a PB!

        However, may I challenge your 'assumption' that your PB would not have any user stories, just a list of loaders. Surely the loaders have functionality such as "As a ... I need to see/use {xyz} data so that ...". If they really don't, then I would question what the business need for this data is.

        Given that you can break down what these loaders are doing, then there is scope for getting user stories in terms of functionality that the business can prioritise and do the detailed understaning and transformation bit by bit in the Sprints, swopping over to the new code once a current loader has been transformed - may take many Sprints.

        Basically you are still pre-project or the unofficial 'Scrum Pre-Game'.

        I would think that your only alternative would be to do a full study of the existing code to understand it and be able to produce a reasonable estimate for thee transformations. The drawback for this is that it will probably take a long time and someone has to pay for it. If this was acceptable, you could still do the transformations incrementally in Sprints; the business would not start seeing benefit until much later.

        --- In scrumdevelopment@yahoogroups.com, "animgpt" <animgpt@...> wrote:
        >
        > 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.
        > > >
        > >
        >
      Your message has been successfully submitted and would be delivered to recipients shortly.