In the process of developing new project methodology standards for a couple of teams within my department, I've been asked several times to explain the difference between a Portfolio, a Program, a Project, a Release and a Sprint. Currently, there is very little version control for development efforts, and I've been "voluntold" to address it in the new process. It makes sense for those that have worked in IT and software development, but in our case, several of the team members are not used to the terminology. And, since I've also noticed similar questions in the Community, here is how I break it down for my groups.
(A side note…I've found it best to use non-technical examples to explain technical concepts; it makes it easier to grasp. In most cases it works, my only failure was trying to use a receiver, amplifier, and turntable to explain Components in Jira. I forgot that I'm old and kids these days have never seen a "component stereo system.)
PMI defines a portfolio as "projects, subsidiary portfolios, and operations managed as a group to achieve strategic objectives. Helpful? Meh. The PMBOK also has an image that is better, for all of us visual learners out here (PMBOK Guide, 6th Ed):
Think, for a minute, of a growing suburb of a big city and picture it from the window of an airplane at 35,000 feet.
As urban sprawl takes over open land we can see that the city planners created residential, commercial, industrial, and agricultural zones within our suburb. That can be considered a portfolio, just as a company's full set of projects can be lumped together into a single portfolio, with sub portfolio and programs for departments within the organization. Looking at our fair city a bit closer, we can see that the Industrial Zone can be broken into sub-zones for Light Industrial, Medium Industrial, and Heavy Industrial, the Residential Zone is separated by Single-Family and Multi-Family zones, while the Farming and Commercial Zones are not yet big enough to warrant further definition.
The PMBOK is a bit more helpful here because "a program is defined as a group of related projects, subsidiary programs, and program activities managed in a coordinated manner to obtain benefits not available from managing them individually." (PMBOK Guide, 6th Ed.) Coming in at 10,000 feet, our Residential Zone portfolio, and the two sub-portfolios for Single- and Multi-Family are now viewable as groups of residential housing developments and apartment complexes. Each of these is its own program; they are comprised of separate houses and buildings.
Here's one we all get: a project is "a temporary endeavor undertaken to create a unique product, service or result. A project is temporary in that it has a defined beginning and end in time, and therefore defined scope and resources." (https://www.pmi.org/about/learn-about-pmi/what-is-project-management)
We've now landed, rented a car, and are driving by our new house. There are quite a few houses in this development, but since it is being built by one development company that shares builders between houses, each house is considered its own project.
When our house was being built, it was put together as a series of Releases, Sprints, and Features in a previous project, called House.
In Jira, and in Scrum overall, a Sprint is a feature or set of features within a product release while a Release is the complete feature set for that particular version of the product. Both are considered "shippable" and able to be consumed by the end user, but generally speaking, the output of a Sprint is just the short-term part of the end product and cannot stand alone while the output of a Release is the long term, the strategic product itself.
Since our new house is already there our new project is to add an addition to the House. The project is to go from House v1.0 to House v2.0 by adding on another room. The Release is the room itself, and the Sprint are the parts of the room. So, the sprints could shape up like this:
Sprint 1: Pour the concrete.
Sprint 2: Build the frame
Sprint 3: Wire the room for electricity
Sprint 4: Hang the drywall
Release 1.1: Turn over to the Decorators
Sprint 5: Lay the carpeting
Sprint 6: Paint
Sprint 7: Add furniture
Release 2: Deliver House 2.0 to the Home Owner.
Each sprint is complete and verifiable in and of itself, but without the other sprints, it is not a complete project.
Each Release can be an endpoint to the project (like House 1.1), if that fits into the strategic goals of the owner, or it can be combined with other releases and delivered as a version update.
OK, this example is getting tired, but it's not quite done yet. Part of the methodology is deciding when stories can be closed, and if they get reopened to correct defects.
So…How do we, as the product owners of the House, know when it is done, and the builders can be paid? An Agile or Scrum methodology needs to include a "Definition of Done (DoD)," or put simply, a set of deliverables that meet certain defined criteria. When each is done it is marked "closed."
Let's say that Sprint 2 "Build the Frame" has 6 stories: Frame the Bar, Frame the Living Room, Frame the Second Bathroom, and Frame the Man Cave.
During the final inspection (UAT) we discover that one of the walls in the Bar isn't level so the ceiling is higher on one side than the other. We let the contractor know, and they come in, tear down one wall, then rebuild it...drywall, electricity, paint, the whole thing.
Is this reopening the story "Frame the Kitchen" or is it new work to fix the mistake?
Under the Scrum or Agile methodology, the "Frame the Bar" story is done; the contractor has moved on to other things. If they were to reopen the story it would mean tearing the mistake down, fixing it, then reopening the subsequent stories to run the electricity, hang the drywall, paint, decorate, etc. (Which, BTW..in a real-life situation increases the work effort for that user story during that sprint, which will overstate the team's velocity.)
However, if it is counted as new work to fix the mistake the estimated cost of the work includes the frame, electricity, drywall, paint, and, once the punch list of "bugs" is finished in an added "bug fix" sprint, the final inspection is redone, the project passed the DoD, and the builders deliver House v2.0.
Scott TheusCommunity Leader
If you already heard about Smart Commits in Bitbucket, know that you just stumbled upon something even better (and smarter!): Genius Commits by Better DevOps Automation for Jira Data Center (+ Server...
Connect with like-minded Atlassian users at free events near you!Find an event
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no Community Events near you at the moment.Host an event
You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events