Please login or join to subscribe to this thread
The point here is to define "agile project". "Agile project" does not exists but while lot of people use it then it could be good to clarify what you are talking about. It does mean you will use an Agile based method? It does mean you will use a specific life cycle (waterfall, iterative, incremental, etc)? Obviously if you will use a Agile based method/framework then the life cycle will be tied to it. But beyond that, it seems to me you are thinking you can have a well defined scope statement before starting the project. Forget about that no matter the approach you use. It has been demostrated by Barry Bohem´s Cone of Uncertainty (search for it). On the other side, Mike Griffiths has wrote here inside a blog the best things I read about the matter. Search for it inside here.
I am making some assumptions based on the limited information in the question.
Project scope does not need to be defined in that manner. And if executing the project using some agile practice, think of the vision statement as the scope statement. What problem are we looking to solve? For instance; By 2021 we want to increase market share to 65%. Also need to understand the customer. From there can map out products or services to support the vision.
Don't spend time upfront building out a book of detailed requirements if when they will undoubtedly change. Stay above the trees and allow for flexibility to constantly drive toward value delivery.
Start with a session to define a vision statement with the right stakeholders. Look at Roman Pichler's Vision Board for an example of how to get high-level scope defined and go from there...
Collecting requirements thru a focus group as you plan is good technique, but be aware of potential group think.
Other data gathering techniques are mentioned in the PMBoK guide. They include reading documents, e.g if there are relevant regulations or standars to follow, or a contract, interviewing key stakeholders like the sponsor, and more.
The list of requirements should be analysed and prioritized, not all of them might be included in the scope, some might be mutually exclusive.
A scope statement should include out-of-scope requirements, and is subject to progressive elaboration as the project proceeds.
Not all requirements are normally known at this stage, so you might want to make assumptions.
I'm not too sure why you would need to have a different scope statement for your project if you intend to use ______ approach. Remember that the scope defines what you intend to deliver with the project while your approach defines how you will deliver it. Since we adjust and adapt as we proceed the what we are trying to achieve may change somewhat but you are still out to solve a specific problem. I like Andrew's approach of tying the vision to the scope, something that should be done regardless of your chosen approach. We should get away from thinking of the scope as a specific deliverable but rather as a specific value.
Can you tell us more about what your role is on the project? Specifically, are you the Product Owner, the Scrum master, or in a more traditional role like Project manager?
An Agile mindset and framework will focus more on "What Does Good Look Like" rather than a traditional scope statement that defines what is and isn't in scope for the project. Once you understand your WDGLL the Product Owner can begin writing user stories for the product backlog.
There are a number of Plays in the Atlassian Team Playbook that could help you center the team on WDGLL, I suggest the following:
They can be found at https://www.atlassian.com/team-playbook
Should the scope statement be Agile, change and adjust as we go. The project can be managed using an Agile Method, the scope can be high level, but Agile?
I am working in a weak matrix company , so I can't say I am the project manager because i don't have the such power because of the structure of organization .Recently we defined a new project in our our engineering department.it is a R&D project that we haven't done is before.
That makes your scope statement much easier; use it to define what you plan as the end result of your research and go from there. For example, I worked on a project to develop a new line of ATM's. The scope statement for one component of the machine was "Engineer a new card reader that prevents data from being extracted from a card via a skimmer. The new card reader should fit the profile of the existing model number XXXX. This effort is for the mechanics of the reader, the firmware of the circuit boards on the device, and the wired connection(s) to the other components of the ATM. It does not include the Extensions for Financial Services interface or encryption methods."
Everything we did for this R&D project fit into the scope statement, and when our experimentation found things that had to be induced to make the device functional we added them to the statement.
In my opinion surveys wont work and as someone mentioned, focus groups promote group think.
Get all your stakeholders into a room , use simple post it notes and get the participants to note down user stories ...." As a ( role ) I would like the system to do ( Functionality ) so that it helps me do ( Business benefit ) "
Get your business analyst or you do the task of grouping similar requirements
This is your Product backlog .
Now you need to "Refine" the user stories further and it may be that they are at a "Feature Level" and need to be broken down further into Epics and then User Stories.
The next steps would be:-
1) User Stories Refinement Workshops (more than one) with Product Owner . The User stories must be
2) Work with your product owner and Business Analyst to define and record acceptance criteria for each user story.
3) You must then Prioritize the user stories with your Product Owner and Business Analyst . You can use MoSCoW
4) Then get an agreement with your product owner what your Minimum Viable Product is that is to be delivered ....It's definitely Must Haves and Most of Should Haves...If time permits, you will deliver the Could have's but the Won't haves are out of scope.
5) This final set of requirements and user stories are your Scope Statement for the Product .
Remember that a Project Scope Statement is more than just the product - it should include
Documentation:- Test Plan/Strategy , Test Cases, Test Report, Design Specifications , Project Plan, Risks and Issues Log, Implementation plan , Support plan , Project Schedule (includes product sprints ) .
Activities :- Solution increment or functionality should be Designed, Developed, Implemented, Deployed, Tested , Shipped . (Using Agile , all these activities could be happening in parallel in each sprint)
So your Overall Project Scope = Product Scope + Project Management Deliverable and activities
Please login or join to reply