Delivering large projects through Agile [closed]

Question

Closed. This question needs to be more focused. It is not currently accepting answers.

---

Want to improve this question? Update the question so it focuses on one problem only by editing this post.

Closed 4 years ago.

Improve this question

How do you deliver Potentially Shippable Code at the conclusion of each sprint when the broader project spans multiple sprints?

Answer 1

As Sklivvz said, your question is not very clear, but you mention in one of the comments:

However, if a project comprises of multiple stories that only make sense as a unit and are too numerous to deliver across a single sprint, then how does that work?

Stories should follow INVEST.

The I in INVEST stands for Independent which means that your stories should not have dependencies between sprints. You should break them down smaller enough so that they can be developed within a sprint.

Potentially Shippable, does not mean you have to ship, but the product owner can always have the choice to ship. For example, if the product you are developing does not meet the features of a Minimum Viable Product then your product manager might not want to ship. However, it is better to release early (and often) so that users can give feedback about the features. Perhaps the initial set of users are internal to your company or from friendly customer.

Answer 2

It's not clear to me why not!

The idea of agile is that your project has variable scope but pre-determined timings. So you time box everything and make sure that at each time box things are either finished or excluded.

In this sense, you have shippable code at every time box boundary (iteration). If your units of work (stories) span multiple boxes, then your team will make no progress until they can ship any unit. Of course, for this precise reason your stories need to be as small as possible.

A project can run for any number of iterations, until there's valuable things to do.

In other words, an agile project must have variable scope and by definition it should be possible to wrap it up at every iteration.

Answer 3

It can be delivered by being deployed on staging environments for customers to play with, or it can be delivered by being packaged into an installer which allows for it to be deployed on any location desired.

It would need to include any changes needed in such environments - such as new config files, db schema changes etc. These should be bundled as part of the deploy package (as manual steps, or better automated steps).

Of course - there is no one answer. Determine with the other members of your team (remember that this includes DEV, QA, Business and 'Customers') in this project what it means to deliver this /Potentially Shippable Code/ to your team. Then deliver it that way. Then discuss how that worked out. Then improve upon it.

Do time-boxed experiments, reflect on what happened, adapt/improve and determine another experiment. That is, IMNSHO, 'Agile'.