Project 6 - Solution for A

Time: 30 Minutes

Product Vision

To develop a tool for Deep Well customers to easily select wells and visualize data that they are entitled
to and to analyze and retrieve data either in real time or for historical queries

Product Backlog
1 Log in to system with credentials or tokens.
2 Establish entitlements for users to access well data.
3 Provide email support mechanism to send visualizations to external sources.
4 Transition to an opensource database solution using MongoDB from existing Oracle
database. Note: This is important to reduce total cost of ownership but requires training for
development team to support new DB solution.
5 Select Source and Customer Destination Well.
6 Select the type of information required: real-time or historical. Note: Real-time data should
be sourced directly from well sensors, not a datastore; this is a technology area that is new
to the development team.
7 Visualize data using Bar Graph, Vector Line, or Scatter Diagram. Note: Visualization
standards need to be defined.
8 Determine historical query parameters based on time ranges, well depth ranges, or a
combination of both.
9 Determine measurement values as either Metric, Imperial, or Custom.
10 Create custom-defined measurement values based on decimal precision and metric type.
12 Provide connection status indicator to show whether well is active or inactive.
13 Set up a mechanism to remove user and well access.
14 Provide a mechanism to export data into different formats.
15 Allow user to scan for new wells and determine whether to visualize data from these
sources.

16 Develop interface to allow external systems to provide data for visualization using industry
standard data exchange format
17 Create interface to financial system to calculate cost and revenue model for well
performance
18 Create mobile visualization application for Android and Apple devices
An example of a prioritized backlog is seen above. Your backlog does not need to look like this, but you
should have something that reflects your interpretation of the priority of the items in the backlog. The
black bar before item 16 reflects the Minimum Viable Product for the project release. The items after
the MVP are very large and not well defined; these would be considered Epics and would not be good
candidates for inclusion in the project release until more details are provided.

The PMBOK recommends some techniques for generating ideas and prioritizing lists; list some of these
techniques and think about how you might apply them.

The PMBOK recommends Brainstorming as a technique to generate ideas. Sections 4.1, 4.2, 5.2, 8.a,
11.2, and 13.1 provide more details on how apply Brainstorming technique. Voting is another technique
for prioritizing items in a backlog. One of the specific Agile techniques is the Fist of Five, where
participants hold their hand up and extend the number of fingers to reflect the priority of a backlog item
with a fist representing zero. Sections 4.5, 4.6, 5.2, 5.5, 6.4, 7.2 and 13.4 provide more examples of
voting techniques. Affinity diagrams (Sections 5.2 and 8.2) are also an effective mechanism to group
ideas into broader categories for prioritization based on the ‘affinity’ of items to one another.

Now that you have a prioritized backlog, what Agile techniques are available to estimate the effort in
delivering these items?

Agile projects emphasize relative estimating to size a backlog. It uses groups of project participants to
compare the size of features, user stories, or product backlog items to one another. This technique uses
Story Points, which do not have a preset definition to participants (like hours or days). Story points are
assigned to each product backlog item using a Fibonacci sequence (1, 2, 3, 5, 8, 13, 21, 34). A product
backlog item sized at 5 story points should be about twice as large as product backlog item sized at 2
story points. You can learn more about story point estimating in the Agile Practice Guide, which is part
of the PMBOK 6th edition (Section 5.4)