There are a couple strategies my company uses for estimating project scope, which are all within a fairly standard Agile development methodology.
The first part of it is breaking the project down into "epics", which are the big, overarching features that the project needs. Things like "user accounts and registration", "customizable dashboards", shopping cart and checkout", etc. If you were to make a landing page to market this product, the features you'd include on that page would probably be "epics", as would the "big ideas" that your client wants. A project shouldn't have more than a couple epics. You really can't estimate the scope of an epic without breaking them down further.
Now you can take each epic and break it down into "user stories". This is still a very high-level overview of the project, not thinking about technical implementation or any of that yet. User stories should be described from the perspective of the end-user, with a common format of "As an X user, when I do Y, then Z." It helps to sit down with the client and discuss user stories together. For example, the "account and registration" epic needs stories like "create account", "verify email address", "login", "reset password". Again, still very high-level, but easier to discuss with the client, and easier to estimate the scope.
There are several ways to estimate scope. One example would be using "story points", and estimating a given number of points on a fibonacci scale. The value of a point might be hours, it might be days or half-days, or something else, but it is designed to be a loose estimate. For example, if estimating with points as days of work, you might not be able to say the number of days the story will take, but you should have a good idea of whether it is closer to a 3 (about half a week), 5 (up to a full week), 8 (at least one or two weeks), or 13 (two or more weeks). Another useful estimation technique is "T-shirt sizes", i.e. S, M, L, XL, which could roughly correspond to the same scopes as I showed with the fibonacci points, but be even more loose since you're not putting any numbers on the estimate.
Generally-speaking, if you have too many "L" or "XL" user-stories, you could probably find a way to break them up into smaller stories that are easier to estimate, and help keep the overall scope in check.
User stories are what you would agree on with the client, but when you start working on a specific story, it may be helpful to break it up further, into "tasks". A task would be a small, focused feature that needs to be implemented, and can be technical. With a "login" story, you know you will need an HTML form, Javascript to submit the form, an endpoint to handle the submission. You don't generally share tasks with your client, but creating and estimating tasks may be useful for you to estimate the time needed for a story.
Writing an essay is not an esay task, And lots of students face lots of problem in writitng it. Well, I am thinking about making app, but I am not good in coding I found it really tough. But hopefully My friend suggest me about andromo.com/ where I can learn making an app, and for that you don't have to do coding much.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
There are a couple strategies my company uses for estimating project scope, which are all within a fairly standard Agile development methodology.
The first part of it is breaking the project down into "epics", which are the big, overarching features that the project needs. Things like "user accounts and registration", "customizable dashboards", shopping cart and checkout", etc. If you were to make a landing page to market this product, the features you'd include on that page would probably be "epics", as would the "big ideas" that your client wants. A project shouldn't have more than a couple epics. You really can't estimate the scope of an epic without breaking them down further.
Now you can take each epic and break it down into "user stories". This is still a very high-level overview of the project, not thinking about technical implementation or any of that yet. User stories should be described from the perspective of the end-user, with a common format of "As an X user, when I do Y, then Z." It helps to sit down with the client and discuss user stories together. For example, the "account and registration" epic needs stories like "create account", "verify email address", "login", "reset password". Again, still very high-level, but easier to discuss with the client, and easier to estimate the scope.
There are several ways to estimate scope. One example would be using "story points", and estimating a given number of points on a fibonacci scale. The value of a point might be hours, it might be days or half-days, or something else, but it is designed to be a loose estimate. For example, if estimating with points as days of work, you might not be able to say the number of days the story will take, but you should have a good idea of whether it is closer to a 3 (about half a week), 5 (up to a full week), 8 (at least one or two weeks), or 13 (two or more weeks). Another useful estimation technique is "T-shirt sizes", i.e. S, M, L, XL, which could roughly correspond to the same scopes as I showed with the fibonacci points, but be even more loose since you're not putting any numbers on the estimate.
Generally-speaking, if you have too many "L" or "XL" user-stories, you could probably find a way to break them up into smaller stories that are easier to estimate, and help keep the overall scope in check.
User stories are what you would agree on with the client, but when you start working on a specific story, it may be helpful to break it up further, into "tasks". A task would be a small, focused feature that needs to be implemented, and can be technical. With a "login" story, you know you will need an HTML form, Javascript to submit the form, an endpoint to handle the submission. You don't generally share tasks with your client, but creating and estimating tasks may be useful for you to estimate the time needed for a story.
Writing an essay is not an esay task, And lots of students face lots of problem in writitng it. Well, I am thinking about making app, but I am not good in coding I found it really tough. But hopefully My friend suggest me about andromo.com/ where I can learn making an app, and for that you don't have to do coding much.