Skip to main content
added 98 characters in body
Source Link
vaughandroid
  • 7.6k
  • 4
  • 30
  • 37

Bear in mind that the main reason Agile processes were created was to cope with shifting requirements. In your case yourIf requirements are set in stone, so (truly fixed requirements are rare but I'll take you at your word here!) then some of the best practices for dealing with changing requirements - e.g. Negotiable stories - become somewhat irrelevant. That said, following a Scrum workflow still has a lot of potential value in terms of scheduling and providing deliverables. Even if your deliverables won't constitute a fully usable product for a while, there's still something to be said for being able to demonstrate progress to your customer (and the team!).

Consider that all those 'must have' stories comprise a single epic: "Be able to compile on platform X". In this case the whole epic needs to be completed before any value is delivered to the user, but this is often the case at the start of large projects. Start with a story to compile the simplest possible program, then create further stories to support more and more language features.

Above all, don't get too hung up on trying to force every situation to fit into a highly generalised approach. Agile is supposed to work for you, not the other way around!

Bear in mind that the main reason Agile processes were created was to cope with shifting requirements. In your case your requirements are set in stone, so some of the best practices - e.g. Negotiable stories - become somewhat irrelevant. That said, following a Scrum workflow still has a lot of potential value in terms of scheduling and providing deliverables. Even if your deliverables won't constitute a fully usable product for a while, there's still something to be said for being able to demonstrate progress to your customer (and the team!).

Consider that all those 'must have' stories comprise a single epic: "Be able to compile on platform X". In this case the whole epic needs to be completed before any value is delivered to the user, but this is often the case at the start of large projects. Start with a story to compile the simplest possible program, then create further stories to support more and more language features.

Above all, don't get too hung up on trying to force every situation to fit into a highly generalised approach. Agile is supposed to work for you, not the other way around!

Bear in mind that the main reason Agile processes were created was to cope with shifting requirements. If requirements are set in stone (truly fixed requirements are rare but I'll take you at your word here!) then some of the best practices for dealing with changing requirements - e.g. Negotiable stories - become somewhat irrelevant. That said, following a Scrum workflow still has a lot of potential value in terms of scheduling and providing deliverables. Even if your deliverables won't constitute a fully usable product for a while, there's still something to be said for being able to demonstrate progress to your customer (and the team!).

Consider that all those 'must have' stories comprise a single epic: "Be able to compile on platform X". In this case the whole epic needs to be completed before any value is delivered to the user, but this is often the case at the start of large projects. Start with a story to compile the simplest possible program, then create further stories to support more and more language features.

Above all, don't get too hung up on trying to force every situation to fit into a highly generalised approach. Agile is supposed to work for you, not the other way around!

Source Link
vaughandroid
  • 7.6k
  • 4
  • 30
  • 37

Bear in mind that the main reason Agile processes were created was to cope with shifting requirements. In your case your requirements are set in stone, so some of the best practices - e.g. Negotiable stories - become somewhat irrelevant. That said, following a Scrum workflow still has a lot of potential value in terms of scheduling and providing deliverables. Even if your deliverables won't constitute a fully usable product for a while, there's still something to be said for being able to demonstrate progress to your customer (and the team!).

Consider that all those 'must have' stories comprise a single epic: "Be able to compile on platform X". In this case the whole epic needs to be completed before any value is delivered to the user, but this is often the case at the start of large projects. Start with a story to compile the simplest possible program, then create further stories to support more and more language features.

Above all, don't get too hung up on trying to force every situation to fit into a highly generalised approach. Agile is supposed to work for you, not the other way around!