Out of scope features

Hello, anyone have a way to control the features being developed using Azure. How to make sure all developed features are within scope? who should be responsible for this control?

4 Likes

The team should be responsible

Do you have a way to control features that are being developed without using Azure?

What is the problem? Within the scope of what, sprint, project, etc? They might be out of scope in some cases. Do you have this issue with any feature?

Specify your issues, provide the context so people can advise you something feasible and relevant

1 Like

A bit hard to understand the question, because everything is technically in scope, especially if you are using KANBAN. That’s going to always come down to “who cares”, because scope is a “cost”, it’s not a Quality issue but a project risk. Better off asking in a SCRUM or other forum really if that is indeed what you are after @roger89 .

Thank you for the clarification, but as company quality (not in terms of testing an app), this is an issue. Some developers, maybe by mistake, add user stories or even without adding anything, and develop out of scope features.

Hi, whitin scope for the whole project. We are using Azure DevOps. How to make sure that nothing has been developed out of scope.

That, feels more like it is a discipline problem than a process problem. Maybe there are not communication processes in place, because user stories come from the product team not from the development team, feels like there is no SDLC in place. Systems development life cycle - Wikipedia
If developers are short-circuiting steps in the cycle, then it may exhibit as a discipline problem when the project manager is not preparing stories to be worked on only when they need starting. Working on a un-prepared story will cause waste and re-work, and should not be possible if the system integration to make the story possible because components it needs normally won’t yet exist. If a story is not ready to be worked on, the software testers are not going to be able to test it anyway. That’s why the SDLC exists, to prevent work on stuff that cannot go through all the quality stages without wasting time. Feels like a communication and architecture discussion Roger.

1 Like

But who and why develop some random features? I don’t get it, you have your scope with some features, plans, deadlines, etc but someone develops features that are not in the scope but why?

You need a Project Manager or a Product Owner to dictate what work needs to be done. There should be targets i.e. sprint goals and release deadlines that should be met. The scrum process (although loathed by some) is good enough to at least keep a project on track.

2 Likes

It’s quite difficult to fully understand the situation from the information you’ve given, but if I understand you correctly, this isn’t a tooling issue.

I’ve worked with many well-meaning developers who will delevop any possible feature or improvement you happen to mention in passing, becasuse they can and they think it will help. However, this takes away valuable time from developing things that have actually been planned and prioritised.

I don’t think your issue lies in how you’re using your issue tracking tool. I think it lies in communication, discipline, and focus. You can do whatever you want in Azure, but it won’t stop people from going off-book.

3 Likes

@roger89 Hi,

You must have a in-house customized Requirement Traceability Page at some centralized documentation system like confluence.

Let me know if you need KPI’s to make one similar kind which I have.

:v:

Isn’t this more the Product Owners job? I don’t see the team being responsible for saying what’s in scope and what’s out of scope.

I’m not 100% sure I understand the original question.

In my experience and following the “agile” way of working, it’s the product owner who decides how the product backlog is build, and what the priority is. Things that are out of scope, will go to the bottom of the backlog or even erased from the backlog.

Then during the sprint planning, the team will plan the in-scope items for the next sprint and they can work on those.

1 Like

Isn’t this more the Product Owners job? I don’t see the team being responsible for saying what’s in scope and what’s out of scope.

If you have one :slight_smile: It might be a project manager (if you have one) or a team lead. Personally, as a QA engineer on many occasions I was the person who stopped devs, the PM, and even FO/PO/PdM from starting spending resources on some tasks that were out of scope (we had some formally fixed scope). Yeah, it was up to the product manager to change the scope but they had to follow the flow, and procedure with some consequences

1 Like

Totally agree, but i raised this question to make sure that i am not wrong. We already have a project lead for each project(Agile). Meanwhile, someone asked me if it would be possible to have a person who can access the project from time to time to make sure nothing is developed out of scope.

This is what is happening with us. We have a project lead assigned on each project. But during the development, some new requests are added. Here, from my point of view the PL should not work on any user stories that are out of scope. To resolve this, the manager asked me if we could add someone who will be making sure no out of scope features are developed. From my side im a 100% sure that must be the role of the project lead when adding stories.

Hey, yes please, anything can help.

DM will be better to proceed further :blush:

Added by whom? Added where to the scope?

I mean c’mon, it’s a simple rule, just a matter of discipline in your situation - if you see a feature that is not in the scope do not develop it. I assume you use some task-tracking tools and you can somehow add labels to the features that are in scope. f you are not sure about the scope - ask the manager.

It might be a surprise but the manager could be responsible for this :slight_smile: it seems as a manager’s responsibility in the first place to monitor such things as scope, deadlines, etc

1 Like