1

Jason Pugatch - Just Appraised Product Case

The following include a proposal and answers to the questions included in the original case document.

PROPOSAL for scoping, building, and launching feature

Scope description: Plan, design, develop, and deploy a reporting feature which gives our customers the
ability to track their team’s progress in processing tasks and surface any bottlenecks. This reporting
feature has the ability to be highly customizable for each customer. It provides different methods for
visualizing the reports. This feature will help users complete work more quickly, route work between staff
members and departments, and allows managers to track work across teams.

Project deliverables:

● Develop visual dashboard with drop down menu for bar, stacked, and pie charts
● Create a way for the dashboard to indicate how many tasks team members are working on at a
given timeframe
● Develop a way for the dashboard to indicate the throughput of each team member
● Develop a way for the dashboard to indicate how many tasks are sitting in each particular
workflow status at a given moment
● Develop a way for the dashboard to indicate whether there are any tasks such in the integration
pipeline
● Develop a way for the dashboard to display whether tasks have been sitting in queue for 7, 30, or
60 days

Project acceptance criteria:

● Successful design of dashboard

● Successful development of dashboard
● Successful development of aforementioned ways in which dashboard will display data
● Successful development of aforementioned ways in which dashboard will track tasks
● Successful deployment for dashboard
● Successful adherence to timelines

Project Constraints:

● Technology Stack: ReactJS, Java, AWS

● Time, money, capacity [I would want the specifics on these items as well as who the stakeholders
for this project are and more details about risks. I already used my five clarification questions with
Shirley to obtain other information around the product so I wanted to mention this point]

Project Stakeholders:

● Product owner(s)
● Project manager(s)
● Developers
● Server-ops
 2

Question: How would you support the Product Manager through the requirements gathering
process of the feature?

A requirement for the feature can be thought of as a need of the user that can be formalized into a user
story. These user stories would be more or less structured in the following way: “As a user I want X in
order to Y”. So an example of a user story in our situation could be: As a user I want to be able to visually
perceive the status of each item within my team’s workflow so I can keep track of team progress. I would
approach the requirements gathering process through 6 steps.

Understand the need: Step 1, which may be the most relevant step in the process, would be to meet with
the user/customer and understand what their needs are and what outcomes they are seeking. In this step
I would also seek to understand the why behind the desired outcomes that the user is seeking. This would
involve considering what issues the desired outcomes would be solving and also what type of
performance the user is seeking from it. The document that I was sent stated that some of the needs of
the user for this feature include the ability to track tasks and visualize reports. This type of clarity early on
in the process is valuable.

Constraints: Step 2 would be to consider the restraints around the delivery of the feature. This could
include time, money, capacity, and regulations.

Knowledge: Step 3 would be to determine if I know what I need to know to properly support the delivery of
the feature. Relevant questions here would include: What is occurring at each layer of the technology
stack? Who are the stakeholders? Approximately how many people will be using the solution? What is the
volume of work at hand?

Who: Step 4 would be to meet with the people and consult the resources that can help me collect
information to answer the questions from step 3. The people here could be stakeholders within the
organization, colleagues or admins. An alternative to consulting people here would be to explore
documentation or doing research online.

How: Step 5 would involve using techniques to gather information around the requirements for the
feature. These techniques could include interviews, workshops, market research, benchmarking,
prototyping, brainstorming sessions, research, and document reviews. For instance, I could choose to
interview/email the engineering manager to collect more details about the technology stack and
approximately how many users the feature would be serving. Of course it is important to try and minimize
the number of meetings to save time for users and the team.

When: Step 6 would be to develop a schedule to collect the information.

These steps cover my approach to the requirement gathering process of the feature.
 3

Question: What tools/frameworks would you use to be able to execute on this project?

● Scrum/agile framework: we would work in an agile framework with 2 week sprints. This is a
cyclical and iterative process that generally includes the following phases: plan, design, code/test,
release, feedback
● Kanban board to track progress of sprint items
● Project management software: Jira
● Dev: Frontend = ReactJS (this would mostly likely involve a UI component library and something
such as redux for state management), Backend = Java, workflow = GitHub linked to AWS
● Deployment: AWS. This could entail services such as cloud front, S3, route 53, API gateway,
lambda etc.
● Communication methods: email, zoom, slack, discord, etc.
 4

Question: What meetings will you need to schedule to ensure that the project is moving along
successfully? Before, during, and after these meetings, what tasks would you ensure you are
accountable for?

1.) Collaboration meeting(s) with stakeholders who own the product backlog to outline/refine requirements
for the features.

● Before: reflect on what I know so far about the product and prepare notes around product backlog
items
● During: participate in the identification of product backlog items/user stories for product
● After: Ensure that new PBIs/user stories are included in Jira. Ensure that refinement is also
reflected in Jira.

2.) Sprint Planning: review the product backlog and see what can be handled in the correct sprint. 3 topics
covered: why this sprint is valuable, what can be done in this sprint, how the chosen work will get done.
Information that goes into this event: ultimate objective of sprint, team capacity, granular look at sprint
backlog. Information that comes out of this event: tasks and risks. Sprint planning usually does not focus
on allocating work to individuals because we may have yet to identify everyone’s workload and discussion
is just being had about what the work entails.

● Before: Have a product backlog created and review it ahead of meeting

● during: Break down product backlog into set of items for upcoming sprint(s)
● After: Make sure that the decisions made during the meeting are reflected in Jira

3.) Daily standup: The purpose of this event is to track sprint backlog progress within a 15 minute time
box. Product owner(s) and developers attend this event. Information that comes out of this event: what
worked, what did not work, adjustments to be made.

● Before: Have a reference of what task(s) each dev is working on and how long the task(s) has
been in development. This is necessary to properly gauge progress. Also have an idea of what
next set of tasks are the highest priority. This allows me to help developers stay productive.
● During: Check in on the status of assigned tasks for each dev on the team. Knowing that a task is
completed allows me to make changes in Jira to reflect the progress.
● After: Ensure that Jira is reflecting any changes on the status of tasks. Follow up through
messages with devs who were experiencing blockers to help troubleshoot technical issues. It is
best to do this detailed follow up outside of the daily stand up in order to save the team time.

4.) Sprint Reviews: at the end of sprints to demonstrate what the team has for deployment and what we
can change for upcoming sprints. This event is for key stakeholders. Information around budget, potential
release, and updated product backlog can come out of this event.

● Before: Make sure the team has something ready for deployment. Also reflect on what can be
changed for the upcoming sprint before entering the meeting.
● During: Demo the product for deployment. Communicate what ought to be changed with the
team.
● After: Follow-up with developers to resolve any last minute fires if any bugs come up during the
demo.
 5

5.) Sprint retrospective: the purpose of this event is for the team to inspect how the last sprint went with
respect to individual interactions and process tools. Time box for this event would likely be no more than
1.5 hours per every 2 week sprint. This event is for scrum teams/developers. Information that goes into
this event: data analysis and lessons learned from the current sprint. Information that comes out of this
event: feedback from developers. The project manager can focus mainly on facilitation to strike a balance
between the product owner and stakeholders.

● Before: Reflect on developer team performance/workflow before meeting

● During: Discuss performance/workflow casually with the team.
● After: Take action if needed on points discussed during the meeting.
 6

Question: What key milestones would we need to hit to ensure that the feature is delivered on
time?

In the process of:

● Identify requirements for the feature (create product backlog out of user stories)
● Determine which product backlog items will be part of the upcoming sprint(s)
● Develop the functionalities for the feature (execute sprint items)
● Run sprint items through QA

The team would achieve the following milestones to ensure that the feature is delivered on time:

● Verify that our developers have clean access to the GitHub workflows and databases by
addressing administration (usernames, passwords, configuration)
● Have the team agree to a consensus around a component library for the UI
● If we need a separate cloud environment/sandbox for running QA then make sure that happens
● Develop visual dashboard with drop down menu for bar, stacked, and pie charts
● Develop a way for the dashboard to indicate how many tasks team members are working on at a
given timeframe
● Develop a way for the dashboard indicate the throughput of each team member
● Develop a way for the dashboard to indicate how many tasks are sitting in each particular
workflow status at a given moment
● Develop a way for the dashboard to indicate whether there are any tasks such in the integration
pipeline
● Develop a way for the dashboard display whether tasks have been sitting in queue for 7, 30, or
60 days
● Check in with server-ops team to ensure that cloud infrastructure is ready for deployment

Question: What is the best way to surface and mitigate risks throughout the project?

● Conduct a thorough QA on all sprint items prior to deployments

● Encourage transparent communication with team so that bugs are addressed proactively
● Track bugs on Jira
● Run critical health checks with server-ops prior to deployments
● Have an estimate around user traffic so that AWS is configured accordingly