Introducing
the known requirements to the feasibility team:
Introducing the known requirements to the feasibility team:
If you’re working on an agile project, one with volatile
requirements or a tight deadline, you won’t have deep requirements when you
begin the Feasibility phase. A request or idea has been approved for a
feasibility investigation, and no one has documented detailed requirements to
this point. Your idea is relatively new, and you’re working rapidly to either
start the project or dismiss it. The information that is available is presented
to the feasibility team. The idea usually has a champion or author who can meet
with the team and go over the concept. This person brings in all the
information they have at this point, whether it’s a diagram on a cocktail
napkin, a detailed flowchart, or a mini functional specification. The following
items can be analysed during the Feasibility phase:
·
User
scenarios
·
Storyboards
·
User
stories
·
Marketing
proposals
·
Use
cases
·
Competitive
analysis
·
Rough
sketches of process flow
·
Financial
analysis
·
A
website where a competitor is already using the idea
·
Mock-ups
If your idea comes from within, you may have a white
paper created by someone to outline the idea.
When you present your idea to the feasibility team, they
will provide initial feedback and subsequent commentary after performing their
offline feasibility work. The initial review can provide positive feedback or
identify issues immediately. You should inform the feasibility team that candid
conversation is not only desired but critical to the process—you don’t want to
go forward with more extensive feasibility analysis if you don’t think the idea
is viable. You should also prepare the idea owner for candid feedback.
Encourage the owner
to demonstrate their passion for the idea, but at the
same time prepare them for frank conversation and a thorough review of the
proposal. The time you spend on feasibility analysis will depend on various
factors such as the idea’s complexity, the availability of the feasibility
team, and dependency on third parties to provide information. An average
feasibility analysis begins with a 1- or 2- hour meeting that kicks off the
process; at this meeting, one person discusses the known requirements with the feasibility
team. The feasibility team reviews the idea with the presenter, and team
members ask questions about the customer, the project’s value, and potential
technology needs.
AGILE PROJECT FEASIBILITY
This first meeting may provide enough information to make the
go/no go decision,
but usually a few questions remain that require team
members to work offline to get the answers. This offline work may include the
following:
·
Looking
at existing code to see how it can support the request
·
Consulting
with a vendor about a possible solution for the request
·
Doing
deeper statistical analysis
·
Reviewing
competitor functionality to see if they’ve addressed the same idea
Typically, the team regroups after 2 or 3 days to review
their offline work. At this point, they usually have enough information to make
the call about whether to continue to the Planning phase.
You can also visit my other blogs-
You can also visit my other blogs-
http://xenelias-scrumblog.blogspot.in |
http://xeneliasscrum.wordpress.com |
That's a really informative article. I liked your approach very much, and it has all the details related to the topic! I just wanted to share this link to another great resource on the same topic - https://www.scrumstudy.com/blog/agile-feasibility/
ReplyDelete