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

Re: Do user stories make sense for a porting project

Expand Messages
  • petriheiramo
    Hi, One additional question before going further: how big is the estimated effort (n people working for x months)? If it s two people for two weeks, you don t
    Message 1 of 9 , Oct 31, 2010
    • 0 Attachment
      Hi,


      One additional question before going further: how big is the estimated effort (n people working for x months)?

      If it's two people for two weeks, you don't need much of a process.

      If it's five people for 8 months, we absolutely need some effective process to manage the whole.

      > Why not User stories:
      > the only "requirement" for porting is, "it works on 32 bit, make it work on 64 bit". I think creating user stories is overkill? If I make a list of fuctionality, e.g., File->open, File->close and make sure they work on 64 bit, it should be enough?

      What is the degree of difference between these environments? As you do, how big changes do you need to do in terms of refactoring the code? How much of the differences can be analyzed by compiling the code in new environment and then fixing the errors?

      > Timeboxing:
      > In the first post, I was thinking that in a usual s/w dev project, during a sprint the team could make some trade-offs while reaching a "done" state. Whereas, for porting, there doesn't seem to be much of a choice/tradeoff - you have to port all files/modules. I was thinking you can just break up the project into 3 week chunks - if you overshoot a 3 week chunk it doesnt matter.

      Projects like this, assuming copying exactly same functionality, tend to follow functionality-driven management strategy, i.e. it is ready when all desired functionality is working, and time and budget change accordingly. What you want in this case is not so much budget or schedule control, except to provide you information when the work can be expected to be ready, and if we need to add/remove people to stay within desired schedule.

      If 3-week chunks allow you to tackle some meaningful scope and prove you've gotten it working, you can use "working code" to measure your progress in the project. You can then put those chunks in the product backlog, and proceed with Scrum easily.


      - Petri

      --
      - Petri Heiramo -- Agile Coach, CST -- Agilecraft Oy
      - GSM: 040-7092 526 -- Email: petri.heiramo@... -
      - Sudenkatu 10 as 41, 48600 Kotka, Finland -
      - http://agilecraft.wordpress.com/ -
      --
    Your message has been successfully submitted and would be delivered to recipients shortly.