Skip to content

5 things to know when creating a use case

What is a use case?

The use case is a tool that a Business Analyst can use when they want to figure out how a process or system will work or react in various situations. Use cases are designed to describe how an actor can interact with a solution to satisfy a goal or respond in a certain way. Each use case should contain one function or action. Use cases often have primary and alternative actions but all possible outcomes should be documented.

5 things to know when creating a use case:

1. Each use case should have a unique name and a description of their purpose;
2. Use cases have actors that represent a person, group, system, or event that interacts in some way. Actors are often represented by stick people in use case diagrams;
3. Use cases have relationships or associations between actors and represents access to a particular function.
4. Use cases have conditions (pre and post) that happen before or after a certain point in time or action; and
5. Use cases have events that describe what the actors and systems are doing in a local flow.

use case example

Posted in 5 Things, Business Analyst, Tools.

Tagged with , .

Project Charter – Template

Lee, Morgan

A project charter can vary in size and detail. I have been asked to create a 1-page charter up to a 30+ page document. Depending on the business need, you may have to create, or help others create a charter that captures high-level project information such as the executive summary, project objectives, project scope, constraints, risks, issues, assumptions, and stakeholders roles and responsibilities.

Attached is a sample Project Charter with questions and descriptions to help fill out the document, including the executive summary, business case, project description, risk management, and roles and responsibilities sections

Project Charter template.

Posted in Business Analyst, Deliverables, Template.

Tagged with , .

Measure success with BI and KPIs

Lee, MorganDoes your company measure project success primarily based on projects being delivered on time or on budget? There are other ways to track and measure success that a lot of companies may not consider; Business Intelligence (BI), and Key Performance Indicators (KPI).

1. Did you deliver all of the features that the client asked (or paid) for?
2. What was the quality of the product that you delivered?
3. Can you track your team’s performance to help improve on the next phase or project?

Often features are removed to meet project time lines and budgets. If a project was completed on time and on budget it does not mean that the highest quality was delivered. With the help of BI and KPIs, we can track and measure performance and help deliver higher quality, on time, and on budget (at least that is the plan).

BI is a process that can help a Business Analyst, Manager, or other stakeholders use the information collected to track business trends, create dashboard reports and create a strategic plan for a new project or altering an existing project. BI can help people see the big picture. Most daily activities can be measured or quantified in some way. KPIs are predefined goals that help determine if you have completed a milestone, if the part you built was completed on time, if the actual cost to build a product matches the estimated cost, if all test scenarios were completed and passed, or one of many other bits of information that is relevant to your project.

1. You can start using BI and KPIs by first defining the business plan and identifying clear objectives.
(e.g., during Phase 1 the development team will deliver 7 requirements worth 22 value points; it will take two weeks to complete. Dave will create requirements #1, 2, 4, and 7. Paul will create requirements #3, 5 and 6. )

2. Identify KPIs to help determine your progress. Make sure you pick KPIs that you can measure. Identify risks and issues and monitor them to see if they appear.
(e.g., requirement #3 is estimated to take Paul 4 days build and must be completed before Dave can start work on requirement #4.)

3. Measure your team’s performance and compare it to the project plan, burndown chart, or whatever tool you are using to track project information.
(e.g., requirement #3 was estimated to take 4 days to complete. Looking at a daily report, the BA tell that on day 3 of this phase it will take Paul 5 days to complete the development for requirement #3. Based on our project plan we will be one day behind schedule if nothing changes.)

4. Adjust your project plan and strategy (when required). Use KPIs to see if you are meeting your targets. You can choose to do nothing or adjust schedules and workloads or add and remove resources to meet time sensitive activities.
(e.g., Dave is scheduled to work on requirement #4 after requirement #3 has been completed. If Dave works with Paul on requirement #3, they can meet the scheduled 4 day target and Dave will not have to wait an extra day for Paul to complete requirement #3. Because of this change, the BA recommended to move requirement #7 to phase 2.)

5. At defined points in the project the team should review what worked well and what didn’t. Identify lessons learned and apply those lessons to future phases and project. Creating BI reports are a great way to compare progress over the project life-cycle.
(e.g., during Phase 1 the development team delivered 6 requirements worth 20 value points. Requirement #7 worth 2 value points will be included in phase 2. Based on this information we will plan to deliver another 20 value points worth of requirements for phase 2. )

BI with KPIs helps plan project activities and refine project estimates. The more project metrics collected and analyzed, the more it can help the businesses move away from the best guest estimates and towards an evidence-driven approach to project planning. Collecting information is useless unless you analyze, identify patterns for improvement, and implement those improvements.

Posted in 5 Things, Article, Business Analyst.

Tagged with , , , .

Value Points (VP)

Lee, Morgan

Value points (vp) are a prioritization technique used to determine the value of an item or activity in a requirements repository or product backlog. Value points can be measured by effort, duration, size, complexity, priority, or another quantifiable, comparable, and consistent value that makes sense for your project.

A team must first create and agree on a standard value to apply to all items being evaluated, and that same value should be consistent through the lifecycle of a project. Using a consistent value is the key to making accurate project estimations.

Scenario: Project XYZ is scheduled to have five phases. Each phase is two weeks long.  The team met earlier to discuss the activities that are required to be completed for this project, how long each activity should take to complete, and the order they should be completed in. The team agreed to the work that each person was responsible for and decided on a value point system before phase one started. For this project, the team agreed that each full work day spent completing activities is worth 1 value point (e.g., 1/2 day of work = 1/2 value point, 1 day = 1 value point, 2 days = 2 value points, et cetera).

The team has 10 activities to complete for phase one. Each activity is estimated to take two days to complete so each activity is assigned two value points for total value points of 20 (10 activities x 2 vp). If the team can complete all 10 activities during phase one, they will have delivered 20 value points.  If the team missed one activity during phase one then they would have only delivered 18 value points (9 activities x 2 vp).

Note: Determine why an activity was missed. The value points for that activity may have been estimated incorrectly, or there may have been other factors involved.

Based on the work delivered  (20 value points) during the first phase, a baseline can be created for future phases.  If the value is estimated consistently, the team should be able to complete another 20 value points worth of activities in phase two. If a normal activity is worth two value points and a larger activity is estimated to take twice as long as a normal activity, then the larger activity could be given a value of 4.  In this scenario the team should be able to complete 9 activities for a total of 20 value points ((8 activities x 2 vp) + (1 activity x 4 vp)) in phase two.

If estimated correctly, the team should be able to complete 20 value points worth of activities for each project phase.  If a specific activity was incorrectly estimated, the team can adjust their current plan, add or remove resources to complete the activity, move the activity to another phase, et cetera.  During a retrospective meeting, planning activity or lessons learned session, the team should discuss and refine their value point estimates for future activities.

Value point estimation may take a few phases or projects before a team can start to make accurate estimates, but if everyone can agree on consistent values and refine those values over time, you will have a great tool to add to your BA toolkit for estimating project activities.

Posted in Agile, Article, SCRUM, Techniques, Tools.

Tagged with , , , , .