4

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?

Improve this question
2
  • 1
    Scrum does not recognize the role of 'PM'. Who is the PM? Is s/he the Product Owner? Is s/he your boss? Are you his/her boss? Do you have the same boss? – Sarov Sep 12 '19 at 13:08
  • Yes, the title is PM, but technically that person works as a Product Owner. He is not my boss and I'm not his boss. – Łukasz Kupiec Sep 12 '19 at 16:57
2

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:

  • You can get regular feedback from your users and so adapt the product to deliver the maximum value
  • Development becomes more predictable as the best indication of progress is when new functionality is genuinely done
  • Value is delivered frequently

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.

Improve this answer
2

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.

Improve this answer
3
  • If you have not completed acceptance tests then you do not have a potentially shippable increment, you just have a work-in-progress. – Barnaby Golden Sep 13 '19 at 4:49
  • 1
    @BarnabyGolden I see your point. In my current situation in a not-really-agile environment, UAT testing involves not only going through a list of defined test cases but users hammering at the system until they feel confident that it's releasable. This process doesn't scale to 2- or 4-week sprints of course because users can't devote that much of their work time to testing. I'll have to read up a bit on this, my feeling is that this indeed requires changes in the user's and management's understanding of acceptance tests and can't be solved by a team doing Scrum alone. – Hans-Martin Mosner Sep 13 '19 at 5:31
  • 1
    It is without question one of the most challenging aspects of doing Scrum. It's worth trying to find a solution to though, otherwise there is always a worry that something major will be found in acceptance testing and the progress that appeared to have been made turns out to be misleading. – Barnaby Golden Sep 13 '19 at 8:35
1

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.

Improve this answer
0

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.

Improve this answer
1
  • Hi Wiz! The concept of "user acceptance" changes considerably according to the environment. In some, a UAT definitely can't fit a Sprint Review ceremony. I agree a demo should be done, and usually this is a lightweight presentation (because the feature itself should be lightweight), right? I believe expanding your answer in one of these two senses could improve it. – Tiago Cardoso♦ Sep 13 '19 at 7:18

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.