Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 1 year ago.
Improve this question
How flexible should a programmer be if a client requests requirements that is not in the project scope?
General perspective:
You need to earn a living; the client needs a computing solution: the client has the right to make sure that the solution you will supply fits his needs. Changes and additions after and agreement has been reached, reflects on your ability to analyze the user's requirements into a system design, in that failed to investigate those requirements to sufficient depth and detail: you need to do this meticulously and obtain a written sign-off agreement on your system design from the client.
Legal perspective:
You should pin the scope of the project down, and get the client to sign an agreement of that scope. Once you have that agreement, anything not covered by it constitutes a new project.
Business perspective:
Do you want to continue doing business (with the current as well as future clients)? You need to do an evaluation of the impact adding the new required functionality will have on the current project: if the impact is small, then do it, but tell the client - in writing - that you are doing him a favor; if the impact is larger then you must negotiate with the client, outlining the issues, and either adapt your current agreement, or make a new one. What you do not want to do is to antagonize your client.
Lastly: "The client is always right." - (up to the point where you have to give up and just go away.)
This question cannot be given a blanket answer. It depends project to project.
Examples:
Client has money to burn, long timeline, no other projects on the go, I am very flexible.
Client is tight with $$, short timeline, other projects on the go, I am hardly flexible at all.
Other factors come into play as well, such as the process that has been chosen for the project. For example, you will be more flexible in an agile process, less flexible in a waterfall approach.
I think the answer to your question comes down to how flexible your client is with time and cost because you can not change the scope of a project with out having an affect of these two things.
Scope creep can be a good thing if it allows the project to evolve and has an overall positive affect on the outcome of a project. You really need a formal change process in place to manage scope changes.
If it's a fixed-bid project, then I am open to negotiation and will agree to expanding the scope in one area in exchange for reducing it somewhere else, or for an increase in budget, or in exchange for some other consideration.
If it's for a client that I'm billing hourly, then they can expand the scope all they want, since I'll be charging them for the time I spend on it regardless of whether it's within the original definition of the project or not.
Define in advance a list of functions that the system will perform.
If the client adds a new function then increment the cost and time accordingly.
If the client decides to leave a function out of the scope then decrement the cost and time if you have not implemented it yet.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
We want to start a new project. Our DB will be Cassandra; and we do our project in a scrum team, based on agile.
My question is that, one of the most important issue is changes, that agile can handle this.
Agile software development teams embrace change, accepting the idea that requirements will evolve throughout a project. Agilists understand that because requirements evolve over time that any early investment in detailed documentation will only be wasted.
But we have:
Changes to just one of these query requirements will frequently warrant a data model change for maximum efficiency.
in Basic Rules of Cassandra Data Modeling article.
How can we manage our project gathering both rules together? the first one accept changes, but, the second one, want us to know every query that will be answered in our project. New requirements, causes new queries, that will changes our DB, and it will influence the quality(throughput).
How can we manage our project gathering both rules together? the first one accept changes easily, but, the second one, want us to know every query that will be answered in our project. New requirements, causes new queries, that will changes our DB, and it will influence the quality
The first rule does not suggest you accept changes easily just that you accept that changes to requirements will be a fact of life. Ie, you need to decide how to deal with that, rather than try to ignore it ore require sign off on final requirements up front.
I'd suggest you make part of your 'definition of done' (What you agree a piece of code must meet to be considered complete within a sprint) to include the requirements for changes to your DB code. This may mean changes to this code get higher estimates to allow you to complete the work in the sprint. In this way you are open to change, and have a plan to make sure it doesn't disrupt your work.
Consider the ways in which you can reduce the impact of a database change.
One good way to do this will be to have automated regression tests that cover the functionality that relies on the database. It will also be useful to have the database schema built regularly as a part of continuous integration. That then helps to remove the fear of refactoring the data model and encourages you to make the changes as often as necessary.
The work cycle then becomes:
Developer commits new code and new data model
Continuous integration tears down the test database
Continuous integration creates a new database based on the new data model
Continuous integration adds in some appropriate dummy data
Continuous integration runs a suite of regression tests to ensure nothing has been broken by the changes.
Team continues working with the confidence that nothing is broken
You may feel that writing automated tests and configuring continuous integration is a big commitment of time and resources. But think of the payoff in terms of how easily you can accept change during the project and in the future.
This kind of up-front investment in order to make change easier is a cornerstone of the agile approach.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 5 years ago.
Improve this question
I need to add an item to our product backlog list that has no (perceived) value to the users.
Context: every week we need to parse and import a TXT file our system. Now the provider decided to change the format to XML, so we need to rewrite the parsing engine.
In the end the user won't see any benefit as he'll keep getting his new data, but we still have to do this to keep importing the data.
How to add an item like this to the product backlog list?
What happens if you don't make the change? Is there value to the user in preventing that from happening? If the answer is yes, I'd recommend tying your business value statement to that. Then, you can write a typical user story with business value and treat it like any other PBI.
It has no value to the user, but it has value to your company.
As company X I want to be able to support the new XML format so that I can keep importing data from provider Y.
How does that sound like? Not all stories necessarily evolve around the end user.
Note: technical stories and technical improvement stories are not a good practice and they should avoided. Why? Because you can't prioritize them correctly as they have no estimable value.
The correct way to do tech stories is to include them in the definition of done. For example: decide that every new story played is only complete once database access is via Dapper and not L2S. This is a viable DoD definition and makes sure you can evolve your system appropriately.
We typically just add it as a "technical improvement" and give it a priority that we think fits. If the user asks you about it, you just explain them high level what the change does and why it's needed.
Don't forget that your application will most likely start failing in the future if you don't make the change. Just tell them that, and let them decide whether they want that or not.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
What do you defines as an impediment? I know that Scrum say that and impediment is something that stop the team from performing the best it can. So basically it can be everything? But where goes the magical line where it becomes and internal improvement?
For example. We want to have more realistic test data in our databases, is that internal improvement or impediment? We as a team could try to solve it in the sprint along with the other stories directly, or we could say that it's an internal improvement that needs to be a story and go into the product backlog.
As I see it we have three options:
1. Handle all internal improvements as stories in the backlog and make the PO prioritize them.
2. Work with them along regular stories in the sprint.
3. Big things goes in as stories and small stuffs we can do directly in the sprint without it effecting the velocity much.
How do you handle this? We need tips and ideas on how we can do this :)
What is an Impediment
An impediment is anything holding the team back. It's a very wide open category that can include things like:
physical hardware limitations
missing or poor tools
personal conflicts
missing skills on the team
missing personal skills
lack of influence or authority
illness
missing knowledge
We often focus on the obvious: tools and authority, but more often it's the intangible that holds a team back. Things like team cohesiveness, knowledge, and experience.
More realistic test data
Don't get caught up categorizing the improvement as internal vs impediment. Our goal is to embed improvement into the natural delivery process. For that reason, my first inclination would be to say all impediments and improvements should be done in the context of delivering. You want improvement to be reflected in the ability to deliver. We want our outcomes to reflect reality. Sometimes improvement efforts mean we temporarily lower velocity in the name of future increases. Sometimes we even permanently lower velocity in the name of quality.
I would suggest finding incremental ways you can get to your proposed end state and implement a little bit of it each time you touch that area, each sprint, and/or each time your prepare another test run (assuming it takes prep time - if not - fantastic!).
Improvements on Backlog
This is your choice and something you should discuss with your PO. Understand that while the PO wants high quality and improved output from sprints, the backlog is meant to represent valuable features/requirements from the user's perspective - not yours. For that reason, I would be hesitent to put improvement items on the backlog. You should ALWAYS be improving with each backlog item. Your PO may also balk at filling the backlog with things they feel should be done as part of normal delivery. Take it as a signal that this stuff is not directly valuable to the user, but a cost of delivering high quality value at a sustainable pace.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
What's a good way to capture user stories when you have features that are common across multiple UI modes?
For example, imagine a commercial flight information system, something someone might use to answer the question "When is flight UA211 expected to land?"
As is often the case, the feature of providing schedule information is common underlying functionality, even though you might ask for it via a desktop web browser, a mobile browser (where you want to apply different style to make it more usable), and maybe even via SMS shortcodes.
Now, that certainly could be a single user story ("As someone meeting a traveller, I want to see flight arrival information so that I can be at the airport on time"). But that seems wrong (and would probably be an epic story, anyway).
You can make it separate user stories ("As a desktop user...", "As a smartphone user...", etc), which I've done in the past, and the team just knows to estimate the first one to include all of functionality, and the subsequent ones to estimate only UI implementation.
A third option is to make the underlying functionality a story isolated from the presentation layer, and then have UI stories: "As a flight info system front end, I want to get flight status information so that I can present it to the user", "As a desktop user, I want to see flight arrival... etc". But that seems artificial.
Thoughts?
dwh
I think the problem is that you are trying to tie the UI functionality to the backend too tightly.
For example, if you break it into a simple story:
A user may want to know the flight status given the flight number.
OK, now, given that you implement that, now you can look at which platforms will be calling this, as, one part of agile is not to over-develop, but in this case, if you have a business need to support mobile and desktop devices, then you should look at implementing this as a REST service, since that is the simplest solution for both to work with.
So the REST service solves the first story above.
Now, you will find that there are other specifics for each platform. For example, is there something on the phone that may already have the information, for example, did the traveller go to a trip site and already enter his info, then you may want to go there, assuming that the traveller is in the users contacts.
Or, if the user is just going to enter a flight number and that is it, then why not just do it as a webpage, as that is the simplest approach that supports both concepts. Then, if you have a url that supports GET, and outputs as HTML then you can easily display.
So, my first story was too simple, you may want to consider whether it is possible to return different types of data, so a user may want to have HTML, PDF, json or xml, but for each of these there should be a business need.
Unfortunately it is hard to answer your question as there are too many unknowns, which is why you are having a difficult time. If you ask the wrong question then you do have an epic, but if you can just break it down to a few simple stories then it becomes much easier to solve.
I would recommend the second option.
As you suggested, the first sounds like too much for a single story, and a story should always fit into a single iteration.
With the third option, the big problem is that you aren't delivering business value at the end of the story, which is generally a bad practice.
There are other ways you could split this work though. You could initially develop a very cut-down, barebones version which would work across all clients, and then refine each of them in subsequent stories.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
In an iterative development environment, such as an agile one, how do you draw the line between a regular iteration and the beginnings of scope creep? At what point do you tell the client that, "No, we can not do that change, because of ?"
agile iterations have fixed scope; the customer agrees to not change the scope during the iteration (though they can cancel the current iteration and start it over). In between iterations, the scope may change - dramatically.
given the above, scope creep by definition cannot occur in an agile project. The notion of scope creep is a legacy waterfall concept which assumes that the entire scope is known up front and will not change for the duration of the project. This concept does not apply to agile methods as long as each iteration has a fixed target.
This is quite simple in a scrum approach. In Scrum you set your sprint time, e.g. 2 weeks, and then fit items into this. When a client wants something added it gets put into the backlog and will be done in a future iteration. If they want it now you will have to explain to them that something will be dropped for that to fit into the iteration.
for me scope creep is happening when new function is added without the schedule being explicitly adjusted.
With agile methods the user is deeply involved in deciding which stories have priority for implementation. Hence the trades-off of one piece function against another are much clearer.
I wouldn't call it scope creep for the users to get the function they choose in the order they influence.
Here's a simple heuristic, regardless of whether you're working on a month-long iteration, 1-2 weeks, or even a Kanban-like environment, where features are added in a continuous stream:
If your PO (or customer) adds features, but expects the deadline to stay the same - it's feature creep: If he changes the scope and his expectations accordingly, it may not be "Scrum" but it is agile.
If your PO adds features that do not bring any value to the customer, then it's scope-creep of the worst kind - waste! If the features bring value, it is being Agile.
I think there are two kinds of scope creep:
1.) The extension of the scope of a project without increasing the payment/budget/time availableto the developers. This can happen in an agile process just us with any other process when the pm/scrum master or whatever doesn't stick to the figures and squeezes another feature into the project/iteration/sprint.
2.) the extension of the scope of a piece of software, beyond what it usefull. I think agile processes might actually help against this kind of problem, because the cost of a feature is very directly communicated to the project owner, so costs, should be very transparent. But the main tool against this kind of scope creep is the same everywhere: With every feature you have to check: do we really need it? Do we need it in this software? Or does it belong somewhere else? Or in management speak: what does it cost to build, what does it cost to maintain (often forgotten), how much does it increase revenue.
The answer to At what point do you tell the client that, 'No, we cannot do that change, because of ?' depends on the value of ?.
There's usually not a good reason to say "We cannot do this change." Some things you might say:
We can do this, but it'll mean X, Y and Z get dropped from the sprint goal.
We can do this, but it'll mean slipping the release schedule.
We can do this, but it will need additional testing.
We can do this, but first we need X hours of refactoring.
We can do this, but first we need to stabilize or revert in-progress feature X.
We can do this, but we could do X a lot faster and still deliver most of the same value.
We might be able to do this, but we need to task it out before we can estimate it.
We might be able to do this, but we need to spend X days doing a spike before we know for sure.
(1)-(5) just boil down to "Writing code takes time" -- with varying levels of detail. The (2)/(3) combo is probably the closest to the traditional idea of "scope creep." (In theory software developed by an agile team is always in a releasable state, but few teams are that good.) But scope creep is only a problem if it means the product owners making unrealistic demands on the development team. As long as the development team provides realistic estimates and the product owners accept them, dev shouldn't care how far the scope manages to creep.
If the development team has an unhealthy relationship with the product owner, and what you really mean is "Boy howdy is that dumb and I do not want to work on it," the usual response is to make the feature look really, really expensive.
Given that one of the main benefits of agile is the exchange of realistic estimates for realistic delivery dates, though, that's not a good place to be..
The most principle weakness of Agile is that most people who are doing "agile" really are flying by the seat of their pants. Things shouldn't change within a single iteration, but you should allow for change outside of that.
If the client is willing to pay, why should you say no? If there is only one client paying for it all, then he pretty much is in full power of what do develop ("if you don't do it, I will take my money and tell someone else to do it"). But of course, if the product has a large audience, then you need to have a well-defined focus of what the product should do, as adding unnecessary features may lower its usability.
Some situations come into my mind, when the development team might recommend the client to not implement some features. After that it's the client's responsibility, if he anyways wants to implement it. If the feature conflicts with some other, more important features, then it would be wise to not add it. If the feature does not give much value to the client, compared to the cost of implementing it, then it might not be smart to burn lots of money on it. Also in some cases it might make more sense to implement some features as a separate program, if their purpose is very much different from the original program - it's better to have many small applications that each do one thing and do it well, than one humongous application that does everything but is specialized on nothing.
Why should you say No? I don't know which flavor of agile development you're using.
Scrum is the most prescriptive / has definite rules to cater to this scenario.
The PO (Product Owner) maintains the (things to do list) backlog. He decides which items go into the backlog and their priority. The PO is free to add more items to backlog at any point of time. He is not free however to change the sprint backlog (i.e the things the team has begun work on for the next couple of weeks)
In case of an emergency (some new knowledge), the PO can choose to abandon the sprint and start a new one with different backlog items.
Scope Creep shouldn't happen any more - unless you bend the rules. You have a truck that will carry 500 boxes (release plan), To add 100 boxes (new features) to the plan, the PO would have to first remove (descope) 100 least-wanted boxes from his original set.