We are building quite a big and important feature in a Scrum Team. The PM wants to put this feature into a separate branch and not deploy it for a 1-2 months so the users can test it properly before release. It seems strangely waterfall for me.
What do you think? Is it ok in agile to do something like that? Or as a Scrum Master should I suggest splitting the feature into smaller pieces and release it frequently?
As a Scrum Master your responsibility is to ensure your team is following the Scrum framework. The best way to do this is to explain the consequences of not following Scrum and how it will impact on the organisation.
Scrum talks about a potentially releasable Increment at the end of each sprint. The value with this approach is that:
The approach that has been proposed with 1-2 months of acceptance testing outside of sprints is not going to deliver a potentially releasable increment. In fact it could be a problem; if major issues are discovered during acceptance testing then the progress that has appeared to be made will have been misleading.
As you mention, splitting the feature up and releasing more frequently is a better approach. I would recommend suggesting this and explaining why it is the better way to go.
Your team produces a potentially shippable product increment at the end of each sprint. Whether this is then subjected to acceptance tests and actually being released is up to the client.
Of course, you split the big feature into product backlog items that can be handled within the Scrum framework so that it will take several sprints until it is completed, but the client may choose not to start acceptance tests before the feature as a whole is available.
The situation is similar to the starting phase of a project. Nobody expects your team to have a complete product fulfilling all requirements by the end of sprint 1 or 2. Users may experiment with whatever increments are produced during each sprint, but acceptance tests for a first release might only be started when the product is actually able to fulfill a reasonable part of the given requirements.
An additional possible approach to consider, which could be taken alongside the admirable suggestions here to split up the feature, is to 'release' sections of the feature but with a 'switch' to allow the feature to be turned off, or only turned on for specific users/in specific circumstances when the first parts of this are released. This may help if you have a regular delivery cadence, and need to take this live with the rest of the code, but will be delivering this in bits. It would help avoid the need for a separate long-living feature branch, and would allow the releases to be de-risked by only allowing specific users to use this functionality in live as it becomes available.
In Scrum team works to provide the shippable product as an output of each Sprint. It is recommended to use the same timebox in each Sprint (1 to 4 week).
According to statement PM wants to put the feature in a separate branch and allow users to test for 1-2 months. Clearly, it's a product delivery from the Scrum team (assuming Scrum team already tested at their end) and Scrum team seems not participating in the acceptance.
Acceptance testing should be performed in the Sprint Review meeting of each Sprint. If the Scrum team is treating the product as delivered before extensive acceptance testing and the team dismantles or move to another sprint with different features and output of testing added in the backlog for future Sprint planning, it might not Anti-Scrum.
