Acceptance Criteria are important.  Unfortunately, we often overlook or undervalue it as an aspect of the iterative planning process. It is super important because projects succeed or fail based on the ability of the team to meet their customers documented and perceivedacceptance criteria. When we clearly define the criteria up front, we avoid surprises at the end of a sprint, or release, and ensure a higher level of customer satisfaction.  In other words we’re able to answer these two important questions: Did we build the right product? And, Did we build the product right?


They are the conditions that a software product must satisfy to be accepted by a user, customer, or in the case of system level functionality, the consuming system.

Acceptance Criteria are a set of statements, each with a clear pass/fail result, that specify both functional and non-functional requirements, and are applicable at the Epic, Feature, and Story Level. Acceptance criteria constitute our “Definition of Done”, and by done I mean well done.

We’re not talking about horseshoes here, and there is no partial acceptance: either the acceptance criteria is met or it is not.


A trap that I encourage my teams to avoid is writing acceptance criteria after development has started. This leads to merely verifying that the functionality built works rather than verifying that the functionality meets user needs and expectations. If we write and review the criteria before implementation begins, we’re more likely to capture the customer intent rather than the development reality.


Acceptance criteria define when a work item is complete and working as expected. Express criteria clearly, in simple language the customer would use, without ambiguity regarding the expected outcome. This sets our testers up for success, since they will be taking our criteria and translating them into automated test cases to run as part of our continuous integration build.


Another trap that I coach my teams to avoid is the how trap. Criteria should state intent, but not a solution. (e.g., “User can approve or reject an invoice” rather than “User can click a checkbox to approve an invoice”). The criteria should be independent of the implementation, and discuss WHAT to expect, and not HOW to implement the functionality.


The Given/When/Then format is helpful way to specify criteria:

Given some precondition When I do some action Then I expect some result

When writing acceptance criteria in this format, it provides a consistent structure. Additionally, it helps testers determine when to begin and end testing for that specific work item.

Sometimes it’s difficult to construct criteria using the given, when, then, format. Particularly when dealing with system level user stories. In those cases, I’ve found that using a verification checklist works well.

Another advantage to verification checklists is that they are also simple to individually mark as complete as we implement functionality.




Sprint planning is a timeboxed working session that lasts roughly 1 hour for every week of a sprint.  In sprint planning, the entire team agrees to complete a set of product backlog items.  This agreement defines the sprint backlog and is based on the team’s velocity or capacity and the length of the sprint.


Sprint planning is a collaborative effort involving a ScrumMaster, who facilitates the meeting, a Product Owner, who clarifies the details of the product backlog items and their respective acceptance criteria, and the Entire Agile Team, who define the work and effort necessary to meet their sprint commitment.


Ensure all sprint candidates meet the team’s definition of ready.  In the days and weeks leading up to sprint planning, the Product Owner identify the items with the greatest value and works towards getting them to a ready state.

  • Assign a relative story point value
  • Remove dependencies
  • Create testable examples
  • Define acceptance criteria
  • Meets INVEST criteria


The product backlog can address just about anything, to include new functionality, bugs, and risks. Product backlog items (PBI’s) must be small enough to complete during a sprint and should be small enough to complete within a few days. All stories must be verified that they are implemented to the satisfaction of the Product Owner. 


Based on historical data of the team, first determine if product backlog items are too large to complete in a sprint.  In these cases, do not consider these stories as valid sprint backlog candidates. Rather, in order to consider for sprint planning, split the stories into smaller pieces. Additionally, each story must be able to stand on its own as a vertical slice.  Therefore, stories should not be incomplete or process-based as a horizontal slice.


To calculate a commitment, mature teams may use a combination of both team availability and velocity.  However, new teams may not know their velocity or they may not be stable enough to use velocity as a basis for sprint planning.  In these cases, new teams may need to make forecasts based solely on the their capacity.


First of all, as velocity is unique to every team, never use another team’s velocity to plan your sprint.  Derive team velocity by summing the story point estimates of all completed and accepted work from the previous sprint.  By tracking team velocity over time, teams will begin to focus less on utilization and consequently more on throughput.


For teams without a stable velocity, each team member should provide three simple measures to determine capacity.  First, what are the number of ideal hours in their work day?  Second, how many days in the sprint will that person be available?  Third, what percentage of time will that person dedicate to this team?


  1. Remind the team of the big picture or goal
  2. Discuss any new information that may impact the plan
  3. Present the velocity to be used for this release
  4. Confirm team capacity
  5. Confirm any currently known issues and concerns and record as appropriate
  6. Review the definition of DONE and make any appropriate updates based on technology, skill, or team member changes since the last sprint
  7. Present proposed product backlog items to consider for the sprint backlog
  8. Determine the needs, sign up for work, and estimate the work owned
  9. Product Owner answers clarifying questions and elaborates acceptance criteria
  10. Confirm any new issues and concerns raised during meeting and record
  11. Confirm any assumptions or dependencies discovered during planning and record
  12. ScrumMaster calls for a group consensus on the plan
  13. Team and Product Owner signal if this is the best plan they can make given what they know right now
  14. Get back to work

Modern Project Management: What You Need To Know & How To Make It Work

tcan be difficult managing a team. If you do it badly, you can confuse your team, shatter morale, miss deadlines, and possibly worst of all: be responsible for leading a disappointing project.

But fear not! We’ve laid out all the modern project management techniques and concepts, along with ways to execute them (and additional reading for each one), so that you can lead your team more efficiently.

Here’s a crash-course in modern project management concepts

If you’re a traditionally trained project manager, none of this will come as a surprise to you. But if you don’t necessarily have a formal background in PM work, and have yet somehow found yourself in the role of project manager (even if that’s not your official title!), having a handle on these basics can help:

Waterfall Methodology

Waterfall has been mostly out of fashion (especially in the software engineering world) for a while now, but many of these other systems were developed as a response to it, so we’ll cover it first.

It was originally adapted to software development from the manufacturing world, and it’s sequential — not cyclical or iterative.

That means you plan the entire project out at the start of the project, and then go down the plan step by step, checking everything off.

Most of us instinctively plan in a Waterfall style (since we’re never taught anything different, unless we go out of our way to learn it), but a lot of its detractors argue that it’s inefficient, especially compared to other styles.

Scrum Methodology

Scrum has its origins in the late 80s/early 90s. Scrum uses incremental, iterative cycles, instead of planning the whole project out at the start.

Scrum also has pre-defined team roles (product owner, development team, and scrum master).

This method acknowledges that customers/clients often change their mind about what they want in ways that can’t be addressed in traditional methods (like Waterfall), and focuses on maximizing the team’s ability to ship products and respond to new requirements as they emerge.

Scrum emphasizes working in sprints of 30 days and also has a heavy focus on daily meetings (standups or daily scrums) while a sprint is ongoing. There are also structured reviews and retrospectives as a part of the process.

Agile Methodology

Agile draws on older methods and ideas going back as far as the 1970s, but became much more popular when 17 software developers came together to write and release the Agile Manifesto circa 2001.

Like a few of these terms, it’s often used as an umbrella term for a set of process, product, and project management techniques.

The idea behind Agile is essentially that you complete small portions of the project/product (vs. a full version of the project/product) in each cycle, and modify the overall project course based on customer/client feedback as you complete cycles.

Getting this feedback as you’re developing the product lets you create something that meets current customer needs, with minimal cost/waste/time spent. Part of the reason Agile has become so popular is because it’s fairly easy to modify for your specific team’s wants/needs.

Lean Project Management

Lean isn’t really a “true” project management method in the way many of these other concepts are, but it has had a lot of influence in product development, so it’s worth touching on.


Like several of these ideas, Lean started in the product development and manufacturing world, created by Taiichi Ohno at Toyota.

You’ve probably heard of the Lean Startup, which codifies a lot of the product development aspects of Lean into a set of business processes and adapts them for the startup world. The fundamental idea behind Lean is more value with less waste — getting rid of the waste in your business processes. Other Lean philosophies include:

  • Anything worth doing is worth doing fast and right
  • Avoiding rework by clarifying objectives and goals (and doing it right the first time, as already referenced)
  • Using iterative cycles, as several of the other project management methods do
  • Eliminate bottlenecks in the work and in the process
  • The last planner principle, which means that you plan in greater detail as you get closer to actually doing the work (instead of planning everything at the start of the project), and create those plans with the people who will actually do the work

How to figure out what works for your team

Some teams work with one specific project management style basically straight “out of the box,” without feeling the need for modification. Other teams take a system and modify it until it meets their needs (or take the big-picture pieces from 2–3 different project management concepts and then work them together into their own system).

Typically, the pieces being modified are:

  • Sprint length
  • Length & frequency of meetings
  • What’s being completed in that sprint / how much feedback you’re getting on it

For example, daily standups are often too much for a lot of teams, so they switch it to weekly. Another option is to do a meeting on Monday to discuss what’s on deck for the week and give your team a chance to ask any questions they have, then a recap on Friday to discuss what got done, what didn’t, and why.

Generally, it’s good to test for about 1–3 months to see if something is sticking.

It’s especially helpful to create (with your team’s input, of course!) a list of problems that you’re attempting to solve by trying out a new project management method. That list will give you a metric as to whether your test was a success or not.

Even after you’ve found something that works really well for your team, it’s still a good idea to do quarterly check-ins and make sure your system is still working as intended. Signs that your project management system needs to be shaken up include:

  • Tasks or projects are consistently falling through the cracks
  • Meetings aren’t as productive as they used to be
  • People are unsure of what they’re supposed to be working on, in what order, when, or why

At Clubhouse, our project management methods have evolved over time as our needs have changed. At one point, we didn’t do daily standups — after employee number six, they were added.

We also have a bi-weekly priorities meeting where we check in on high-level goals (our Epics) that we set in the Milestones for the quarter. Those meetings were also added after we had a team of 6–7 employees and some of the team went remote.

When it comes to responsibilities, our team members are in charge of their own Epics. They don’t have to do all the work, but it is their job to herd their own cats to whatever degree they need herding.

All that said, we’re still fairly light-touch, because we’re such a small team and we all communicate so regularly. An overwrought system wouldn’t work well for us — it’d just weigh us down.

Our goal is to keep responsibility in our individual team member’s hands, instead of being held in the hands of one specific member or manager.

We’re a small, cross-functional team, with constantly overlapping work — a change in any one department can have effects that ripple across to other departments. Because of that, conversations need to happen out in the open instead of just using one person as the go-between, and our project management methods are designed to reflect that.

Project Management Definitions

Definitions of Project Management on the Web:

* Project management is the application of knowledge, skills, tools and techniques to a broad range of activities in order to meet the requirements of the particular project. A project is a temporary endeavor undertaken to achieve a particular aim. Project management knowledge and practices are best described in terms of their component processes. These processes can be placed into five Process Groups: Initiating, Planning, Executing, Controlling and Closing. …

* The leadership role which plans, budgets, co-ordinates, monitors and controls the operational contributions of property professionals, and others, in a project involving the development of land in accordance with a client’s objectives in terms of quality, cost and time.

* A controlled process of initiating, planning, executing, and closing down a project.

* Both a process and set of tools and techniques concerned with defining the project’s goal, planning all the work to reach the goal, leading the project and support teams, monitoring progress, and seeing to it that the project is completed in a satisfactory way.

* The application of modern management techniques and systems to the execution of a project from start to finish, to achieve predetermined objectives of scope, quality, time and cost, to the equal satisfaction of those involved.

* Project management is concerned with the overall planning and co-ordination of a project from inception to completion aimed at meeting the client’s requirements and ensuring completion on time, within cost and to required quality standards. Project management is typically carried out either by a private consultant or an employee of the project client.

* Manages the production of projects with schedules and tasks associated with the project. It often involves detailed expertise in many of the following areas: planning, cost management, contract negotiations/procurement, technical writing (proposals, etc.), research, technical development, information/computer management, business development, corporate/administrative management, time management, and others. …

* The methods and disciplines used to define goals, plan and monitor tasks and resources, identify and resolve issues, and control costs and budgets for a specific project.

* May be used in a project manufacturing environment for production scheduling or in a variety of one off projects throughout all types of organisation.

* The action of managing a project. It can involves many activities, from scheduling to communication. Project Management in TOC is outcomes based as opposed to activity based, and TPACC software is an ideal tool used to measure the progress toward the financial outcome.

* Approach used to manage work with the constraints of time, cost and performance targets.

* This is managing the resources needed to ensure that a project is finished on time and within budget and to the satisfaction of the end user. Project managers use tools such as PERT and Gantt charts for scheduling all the tasks that need to be completed. They are conscious of managing time, scope and resources for a project. To reduce time to complete a project the manager might decide to employ more workers which would increase costs. …

* The planning, control and co-ordination of all aspects of a project, and the motivation of all those involved in it, in order to achieve the project objectives.

* Project management is the discipline of defining and achieving targets while optimizing the use of resources (time, money, people, space, etc). Thus, it could be classified into several models: time, cost, scope, and intangibles.

Project Management activities

Project Management main phases
Project Management main phases (Photo credit: Wikipedia)

Project Management is composed of several different types of activities such as:

1. Planning the work or objectives
2. Analysis & Design of objectives
3. Assessing and controlling risk (or Risk Management)
4. Estimating resources
5. Allocation of resources
6. Organizing the work
7. Acquiring human and material resources
8. Assigning tasks
9. Directing activities
10. Controlling project execution
11. Tracking and Reporting progress
12. Analyzing the results based on the facts achieved
13. Defining the products of the project
14. Forecasting future trends in the project
15. Quality Management
16. Issues Management
17. Issues solving
18. Defect prevention
19. Project Closure meet
20. Communicating to stakeholders

Software/Web Project Management

Project Planning

The purpose of Project Planning is to identify the scope of the project, estimate the work involved, and create a project schedule. Project planning begins with requirements that define the software to be developed. The project plan is then developed to describe the tasks that will lead to completion.

Project Monitoring and Control

The purpose of Project Monitoring and Control is to keep the team and management up to date on the project’s progress. If the project deviates from the plan, then the project manager can take action to correct the problem. Project monitoring and control involves status meetings to gather status from the team. When changes need to be made, Change control is used to keep the products up to date.

Software requirements

Requirements analysis is a term used to describe all the tasks that go into the instigation, scoping and definition of a new or altered computer system. Requirements analysis is an important part of the software engineering process; whereby business analysts or software developer identify the needs or requirements of a client; having identified these requirements they are then in a position to design a solution.

Risk Management

Risk Management is the process of measuring, or assessing risk and then developing strategies to manage the risk. In general, the strategies employed include transferring the risk to another party, avoiding the risk, reducing the negative effect of the risk, and accepting some or all of the consequences of a particular risk. Traditional risk management, which is discussed here, focuses on risks stemming from physical or legal causes (e.g. natural disasters or fires, accidents, death, and lawsuits).

Software Process

A software development process is concerned primarily with the production aspect of software development, as opposed to the technical aspect. These processes exist primarily for supporting the management of software development, and are generally skewed toward addressing business concerns.

Problems in Software/Web Projects

The problems in software projects come from three different viewpoints. There are project managers,developers and customers. The problems faced by project managers if he/she poor in role definition, poor in estimating and planning, lack of decision making skills. Project managers do need to face the schedule, budget and quality constraints. However, the problems faced by developers if he/she is lack of knowledge in application area, lack of standard, lack of up to date documentations, deadline pressure, changes of application requirement. Lastly, the problems faced by customers is the monetary constraints, receive the products out of the actual time that should be deliver.


Organizing and Planning Project Management
Organizing and Planning Project Management (Photo credit: FreelancersElite Graphics)

Why, What, How?

Planning a project is where the Project Manager must bring together the complete understanding of the project’s requirements with a deep understanding of all the elements that are required to conduct a successful project. In many ways, it is the center-piece for the Project Manager’s skills. Of course, it all counts for nothing unless it leads to a successful project!

Planning, estimating & resourcing – available as a PowerPoint slide Planning, estimating and resourcing may be viewed as separate issues, but they need to be conducted in parallel as they directly affect each other.

* Planning is the definition of work to be done, including resource requirements, dependencies and timing.
* Estimating is the calculation of the amount of time and effort that will be required per type of resource for each part of the work to be done.
* Resourcing is the allocation of actual resources (usually the project’s workforce) to the plan.

The availability of resources will always be limited. Resources may be required in greater quantities than are available or have competing demands on their time. It may be necessary to make compromises or move work between different potential resources to make best use of the resources available. As these practical adjustments are made, there will inevitably be an impact on the duration and timing of tasks. It may also affect the project’s predicted costs.

Here are some of the key issues in deciding what approach to take:

* top down or bottom up?
* all in one go or exploding detail in stages?
* fully detailed or streamlined / summary?
* one plan or several sub-plans?
* automated scheduling or manual scheduling?
* activity, process, deliverable, outcome, or milestone-focused?