How to deliver a feature if it needs more than 1 sprint ?

If say 5 sprints are required to deliver the Feature completely then is it a good practice that Developers keeps the code 'hidden' in the application? and then enables it once feature is fully developed.

@SUMIT AGRAWAL, What purpose would hiding it serve? What does Scrum say about the state of an Increment at the end of a Sprint? Consider understanding the difference between potentially releasable vs. should be released.

Steve, agree with you.

But since the Feature is spread into 5 Sprints, does it makes sense to call it as 'Potentially releasable' after the 1st sprint? (because entire feature is not ready yet)

How to handle this situation?

But since the Feature is spread into 5 Sprints, does it makes sense to call it as 'Potentially releasable' after the 1st sprint? (because entire feature is not ready yet)

How to handle this situation?

@SUMIT AGRAWAL, In my previous reply, I mentioned Increment as opposed to a Feature. I do not have enough info to understand why you would spread a feature across multiple Sprints. I am therefore assuming that a Feature consists of a collection of functionality, that together, as a whole, provide some value to the customer. Can we consider that, if the objective of one of your Sprint's is to deliver a part of the functionality that comprises the overall feature, then that independent functionality is potentially releasable? Then, at the end of each Sprint after the previous one, are you adding new functionality to the existing functionality such that overall they work together as expected and are potentially releasable?

I do not have enough info to understand why you would spread a feature across multiple Sprints

-> Features are spread across multiple sprints as it cannot be delivered in single sprint.

@Steve, yes you are correct. Feature consists of a collection of functionality.

If at the end of the sprint, we are delivering only part of the feature which does not add value to the customer, so in this case should we make it hidden on the web page (to avoid confusion to end users) ?

I've come across two main solutions to this type of problem - feature branches and feature toggles. I'm not going to get into the technical details of them here, but there are methods of keeping functionality that isn't ready yet from being available in production. I'd like to point out that feature toggles have another use - they can be desired functionality to allow for customization based on user desires or what the user is paying for in addition to hiding functionality.

Now, consider some of the principles behind the Manifesto for Agile Software Development. We want to deliver working software frequently. Delivering this working software is the primary measure of progress. We satisfy the customer through delivery of valuable software.

This gets to a fundamental question: What does it mean to deliver software?

If you go with a feature branch approach, your feature won't be available in production until it's done, merged, and deployed. If you want to get feedback, you'd need to be running the software somewhere else - perhaps a feature environment that end users have access to. Of course, you could not deploy this software anywhere that is accessible, but you run a huge risk of spending multiple Sprints building the wrong thing and not knowing. But there's added costs in maintaining infrastructure to support demonstration of feature branches in their own environments.

If you go with feature toggles, you can hide the new functionality behind flags. These flags could be something that users (or a subset of users based on permissions) can toggle to start to see functionality. They could be configuration based as well, meaning they are on in some environments and off in others - perhaps off in production but on in demonstration environments. There's some risk depending on who can change a feature toggle, if it's visible in the UI.

Either way, appropriate slicing of the work can ensure stable software in one or more environments that can be used to elicit feedback from stakeholders and that should be the primary consideration - validation of what you are building quickly and early in the process.

If say 5 sprints are required to deliver the Feature completely then is it a good practice that Developers keeps the code 'hidden' in the application? and then enables it once feature is fully developed.

It can be; particularly in an environment where code is merged and deployed as each item is completed. This mitigates some of the risk of releasing, by limiting the size of each technical change.

However it doesn't necessarily mitigate the risk of enabling a large chunk of functionality to real users and customers in one go.

Feature flags are certainly one option, and my colleagues do use them when it helps, but another option for hiding functionality could be completing items in a clever order.

For most of the time, the value of the feature might be minimal, but with enough collaboration, it should be possible to get feedback from real users

Imagine your feature is adding blog capabilities to an existing content management system.

Items might be completed in the following order:

1. Create page to view an existing blog post
   
    - a basic data structure needs to be created, and data would need to be manually added to the database, but it could be inspected by anyone you share the URL with. e.g. //blog.example/post/1/
2. Make it possible to create blog posts, perhaps only with plain text
   
    - this could be inspected at //blog.example/admin/post/new/ and the saved content viewed at the URL from step 1
3. Add editing functionality
4. Add delete functionality
5. Add a list page, so that users don't have to know the correct URLs to add/edit blog posts
6. Add the list page to the menu of the admin panel, so admins can start using it.
7. Create an index page, so end users can start viewing the blog
8. Iteratively add richer formatting
9. Iterate over the design / UI / UX
10. Add commenting functionality (again, split it in a similar way as the posts functionality)
11. Add reporting functionality / dashboards / analytics
12. Continue iterating

The point is that it might take just as long (or perhaps even longer) before it's properly adopted and used by the customer, but with this approach, you can get early feedback in a controlled way.

If customers have a problem with the way a blog post is going to look, you're probably better off knowing that after (or during) Sprint 1, than another 4 sprints later.

If at the end of the sprint, we are delivering only part of the feature which does not add value to the customer, so in this case should we make it hidden on the web page (to avoid confusion to end users) ?

How would you empirically validate any work that was hidden, and what purpose would Scrum serve in its development?

yes you are correct. Feature consists of a collection of functionality.

If at the end of the sprint, we are delivering only part of the feature which does not add value to the customer, so in this case should we make it hidden on the web page (to avoid confusion to end users) ?

@SUMIT AGRAWAL, I was going to ask exactly what @Ian Mitchell has asked above. Also, it appears that you are still confused between potentially releasable and should be released. At the end of a Sprint, you need a potentially releasable Increment, but it is not mandatory that it has to be released. Also, both @Thomas Owens and @Simon Mayer have offered some excellent approaches and perspectives.

What I still lack clarity from your question is, is the independent functionality of absolutely no value to the customer? Perhaps as a team you need to consider if you need to think differently to approach the way you tackle work?

Thank you everyone for the reply.

I have summarized the answers - 

We will NOT hide any code and we will NOT enable it in one go when COMPLETE FEATURE is ready (say may be after 5 sprints). There is no room for FEEDBACK in this approach.

At the end of a Sprint, you need a potentially releasable Increment, but it is not mandatory that it has to be released.

Also, appropriate slicing of the work can ensure stable software that can be used to elicit feedback from stakeholders and that should be the primary consideration.