Projects that adhere to an Agile SDLC allow for iterative development, leading to quicker results for customers. However, many times the requirements you have at the start of an Agile sprint differ fr

Projects that adhere to an Agile SDLC allow for iterative development, leading to quicker results for customers. However, many times the requirements you have at the start of an Agile sprint differ from the results you see at the end of the sprint.

How can stakeholders be flexible in terms of scope and requirements when running an Agile project? What type of expectations would you set with your customer (internal or external) when running a project based on the Agile SDLC, and why?

Post your answers to the discussion forum.

Respond to at least three of your peers. In your response, consider providing other expectations to expect. 

PEER 1

The way a stakeholder can be flexible during the scope of Agile project, is by realizing they might get everything all at once. They may have a full list of idea/concept that they would like to be include within a project. An Agile project is stage by stages process mini rolling out deliverable of the whole project. If the stakeholder is a software developer company you should like this mini roll out deliverable. An example might litigation support company providing update version of an application that their customer almost daily. It provide an opportunity to prevent any problem in the software and give chance for improvement. However, if the stakeholder happen to be airplane company the internal expectation condition might be the issue might be not resolve if there an issue with a series of planes

PEER 2

I think that the biggest thing that you can do up front is set up expectations. Usually this is specifically with budget and time to completion. With an agile SDLC comes a lot of customer involvement and it is a delicate balance of getting what you want within the constraints. In some of my prior projects we have "acceptable" changes meaning that it won't change the approach nor code of the project. Those changes can be added without increasing the time or budget of the project. If the change falls outside of these constraints then another discussion needs to be had to see if their change will be worth it to them.

I like to apply it to building a house. When all the walls are framed and you decide that you want to move one, or add a window it is quite a bit of labor to do so. But if you change your paint color or carpet selection its not a big deal. However that window may be worth the extra money because its not something that you can add easily down the road. It all comes down to setting up expectations, staying on budget, delivering on time and deciding if changes are worth shifting all of that.

PEER 3

My understanding of Agile if applied to how stakeholders can remain flexible, is basically not to have any deep expectations regarding the results. Simply to see if something will "work" versus be tried and true tested are totally different results. If stakeholders aren't anticipating there will be later problems the scope and requirements the product will be held to uphold won't be as stringent, and may lead to future problems legally. However, that isn't necessarily the case, and most businesses prefer to accept the lower bar in performance in order to best the company bottom line and profitability.

Personally, (internal or external) expectations in developing a project based on Agile SDLC everyone would have to be on the same page with regard to expected results, anticipated regulations, project scope and requirements, additional testing would have to be minimized, and the resultant losses would have to be built into the anticipated profitability, mostly because there would be no "redo" button to correct the product or project. Basically it would result in a pass/fail assessment, with the results hedged on first result profitability being the ultimate baseline.