TL;DR No. Product and Sprint Backlogs should be organized in priority order. Themes, Not Epics To understand the difference between epics and user stories, there's no better source than Mike Cohn's blog entry on the topic. An epic is a large user story that needs to be decomposed before it is pulled into a sprint, while a theme is a collection of related user stories. What you're describing are stories that share a theme, not epic stories. Sprint Backlogs Are Ephemeral You're violating some very basic principles by having a Sprint Backlog that contains items not intended for the current sprint. The Sprint Backlog is built during Sprint Planning, and generally contains just the tasks needed to complete the user stories selected for the current sprint. The Product Backlog is the project's long-term planning tool. The Sprint Backlog is just for the current sprint. Anything not done at the end of the current sprint is either discarded or placed back on the Product Backlog to be (re-)prioritized by the Product Owner. Prioritization Order The Product Backlog is always organized in priority order. What "priority" means is up to the Product Owner, and the Development Team must always peel stories off the top of the Product Backlog. (Note: The Product Owner can change the priority of items in the Product Backlog during Sprint Planning, so there's plenty of wiggle room if the team needs it.) The Sprint Backlog belongs to the team, and should also be in priority order, although that's not a hard requirement. It's up to the team to define "priority" to suit their own needs. Some projects prioritize low-hanging fruit, while others try to get the hard stuff out of the way first. Since each sprint should have a single over-arching Sprint Goal, it seems unlikely that a well-run Scrum would have multiple themes in a given sprint, but it is technically possible. If that's the case, then you could certainly do a stable sort by grouping your Sprint Backlog items first by theme, prioritizing each theme, and then prioritizing at the story- and task-level within each theme. I will strongly suggest that if your Sprint Backlog is complicated enough to require comprehensive sorting, then you are probably doing something wrong at the Backlog Grooming or Sprint Planning levels. The entire process is worth discussing during your Sprint Retrospectives, at any rate, since each team's needs will vary.

The variance here in punishable. That is unfortunate. It is imminent that you will be punished because it is certain that there will be variances. Hoping or trying to have a near zero variance, or zero variance, is to suggest it is possible we can predict the future accurately and precisely...which we cannot. Accurate Estimates is an oxymoron. First you need to understand there is a real difference between an estimate and your planning values. An estimate is ALWAYS a range and your planning value is the number you are hanging your hat on. In other words, you estimate that this task will take from 10 days to 25 days. Your planning value is 19 days. See the difference? Your goal here is to choose a planning value where most of your probability is behind you and not in front of you, but where you don't build in too much wasted fat. The choice needs to be consistent with your organization's risk tolerance. Since you are in a zero variance culture, that implies not a lot of risk tolerance so you are going to be on the fat side of your estimates. It's expensive but safe to operate that way. But I think your real challenge here is training your organization about the realities of estimation, aleatory risks, and the unrealistic expectation of this notion of zero variance.

TL;DR You need to build consensus around "value" and select a methodology for comparing projects in the product portfolio against each other in a way that is inclusive of all your stakeholders. Define Value The first thing your organization needs to do is define "value" in the context of your group. Value will be defined differently by each organization and each stakeholder, so you need to build some consensus first. Prioritization Categories Prioritization can be done in a lot of ways, but in my opinion these boil down to just a couple of broad : Prioritize the low-hanging fruit. Prioritize based on cost/benefit. Prioritize based on contractual or compliance requirements. Tools/Techniques There's no "One True Way" to prioritize anything, but in most cases I think that cost/benefit analysis is the right way to go. If you decide to go that route, then I think that relative weighting is a good approach. Mike Cohn describes his web-based relative weighting tool this way: Relative weighting is a prioritization approach that considers both the benefits of a feature and the cost of that feature. If you have no other drivers, then using a technique like relative weighting might be good fit because it's somewhat quantitative, while still allowing for subjective fudge factors in various aspects of the estimation process. The real key, though, is to build consensus around a set of priorities that aren't based primarily on political capital. ROI and cost/benefit analyses are often great options for exactly this reason, and relative weighting can really help in that regard. Your mileage may vary.

Before I reply I should point out that I really hate Scrum's estimation and velocity as it's traditionally done, so while this might give you some ideas, feel free to adapt your existing process accordingly. The reason you're having to split "epics" into smaller stories and features is because they won't fit into the timebox of a sprint. There are only a few reasons to estimate and use timeboxes: To engage stakeholders at regular intervals and get their feedback (those might be live users if you're actually releasing) To get the trust of stakeholders, when they see that you can deliver what you said you would To let people adjust scope based on history To work out whether there are any elements of the problem you're solving that you might have misunderstandings about; different estimates can show this up. Getting stakeholder feedback You don't need to break things down to get feedback, if you're just focusing on doing something that will get stakeholders' feedback. Pick whichever thing you think you might need feedback on, then get something working and make it increasingly realistic within the timebox (and if you can get feedback early so much the better!) For instance, I hard-code a UI and show it to someone, then I get it working with a hash-map in memory, then I couple it to the persistence layers and thence the database (when the users are the stakeholder who is most able to give me feedback, anyway). Getting stakeholder trust If your stakeholders don't trust you, focus on delivering something valuable. You might need to split up your "epics" to do that, but this should be your focus, rather than "get something done within the sprint". If this is the case, pick small, safe things that you can do easily and quickly, because your relationship with the stakeholder is probably the biggest risk. After you've got their trust you can start trying the tricky stuff and getting their feedback. Release planning and scope adjustment If you want to adjust scope based on history, you can always do it with the original "epic" estimates. These are estimates, so they're likely to be wrong; you can't use a small sample of them to predict the future, so the scope adjustment is likely to be continuous and getting smaller as you approach release. (Ideally you're creating a Minimum Viable Product and releasing anyway so this point is moot). Discovering uncertainty and misunderstanding If you're using estimates to discover misunderstanding, you may still miss some. I suggest talking through examples of how the application might work instead, a la BDD. Split them up as and when Rather than focusing on having small enough stories for a sprint, you may find it more useful to focus on the reasons for having the sprint in the first place. Whatever you find yourself working on as a result, put it on the board, and life will be much easier, with shorter planning meetings. It may help if you work out whether your "epics" are capabilities (provides the capability to trade copper, for instance) or features (one of potentially many concrete user interfaces that provide the capability). Splitting capabilities into features and having some wireframes sketched out before the sprint is IMO fine. After that, leave the dev team free to split up the stories as they see fit, based on the principles above. This will also help you get a self-organising team, and gives the team a clear focus for each timebox. Craig Larman told me that the original reason for month-long sprints was because you could actually focus on small releases, with only the different MVPs being prioritised by the business. Feedback was available all the time, and how much could be achieved, and released, within that month was completely down to the dev team. I think this original vision of Scrum has been corrupted and is much missed. If you're thinking of splitting your stories into tasks, please read this too.

Since you've marked your question as Scrum, my advice to you is to have your Product Owner talk to the stakeholders. Both the ones sponsoring the project (in your case, the teacher), and the ones who (hypothetically or otherwise) would actually use the system. If you don't have any users, go out and find some! Interview random people (or, failing that, friends and family), asking them what they would like the product to do if they were to actually use it. Market research! With that done, epics should evolve naturally as you compile all the requirements (both feasible and not) that the Product Owner has gathered. In the end, the point of Epics is essentially to group Stories, after all. Doesn't make much sense to have Epics if you don't even have any Stories. Now, to actually answer your listed questions... 1 and 2): Stories should be written from the perspective of the person who actually wants the requirement. 'User' fits fairly well for all of the above. A typical developer won't really care if an application they're never going to use can be used offline or not. If you had something along, say, the lines of security, though... 'As a user, I want to make sure all the SQL is sanitized so I cannot break through into the database and steal all the company's information' doesn't really jive. In some cases you can/should get more specific, such as 'As an experienced user, I want hotkeys for (feature), so I can complete it more quickly', or 'As a novice user, I want the usability of (feature) to be simple enough that I can figure it out without needing to check documentation.' 3 and 4): It seems to me that all of the ones you've provided there are more 'stories' than 'epics'. As a general guideline, each story will have one requirement, while each epic will have many requirements. Epics I've seen are more along the lines of 'User Interface Design', 'Integration with Order Management System', or 'Image Attachments'.

If you want multiple 'projects' to be on the same Scrum-board Sprint, then you can accomplish that by having a board with the JQL filter set to read from multiple JIRA projects (ie. 'project = MultiTestOne OR project = MultiTestTwo ORDER BY Rank ASC'). Boards and projects are set up 1-to-1 by default when you create a project, but there's nothing stopping you from later altering the JQL. As for Epics: without further information on what exactly you mean by 'project', I can't give an opinion on whether or not they would make sense via Epics. If it works and everyone on your team is okay with it, though, then I don't see why not. At their heart, all Epics in JIRA are is simply a way to group Issues. Without further information, I can't possibly decide for you which of the two (or a perhaps a third) options is the best for your situation. You need to discuss with the Team to see what makes the most sense. As a side note, you stated that The development team will be working on several different projects in any given sprint. What is the reason for this? Are the projects highly related? Are they just so small that doing only a single project per sprint is infeasible? If the Development Team is working on a multitude of unrelated tasks during a sprint, you may want to consider an approach other than Scrum, such as Kanban.

Let me sum these up and provide a little more clarity since I can't comment yet. Jira no longer shows Epics in the same manner it shows stories. In the past you could prioritize the Epic itself by moving it up and down the product backlog, or within the scrum board itself. While useful that had some problems of it's own, and in the newer versions of Jira Epics no longer function like stories and must be handled in the backlog. Almost the same question was answered here: https://answers.atlassian.com/questions/33139464/is-there-an-easier-way-to-prioritize-epics-in-a-scrum-board-backlog-other-than-drag-and-drop-in-the-filter-pane- The response is basically saying the only way to order the Epics is to drag and drop them in the dropdown on the left of the product backlog view (this is collapsed, look for "Versions" and "Epics" reading lengthwise to the left of your stories in the backlog, click on "Epics" to open the pane). Once you have assigned stories to Epics they will get the appropriate Epic label with an assigned color, which is visible in both the backlog view and the scrum board (Clicking on Active Sprint). From there simply drag and drop your stories appropriately using the Epic labels as visuals. So using your example it would look more like this: (Epics pane) Epic 2 Epic 1 (Backlog) Story 22 (Epic 2 label) Story 21 (Epic 2 label) Story 11 (Epic 1 label) Story 12 (Epic 1 label) Once you have prioritized your Epics in the Backlog add the Epic swimlane to your scrum board, which will allow a better visual of work within the Epics. They will show on the board according to the priority you gave them in the backlog. For further questions about Epics in Jira read through the help here: https://confluence.atlassian.com/agile/jira-agile-user-s-guide/working-with-epics

I worked with an organisation that had a similar problem (although we were using Scrum rather than Kanban). What we found was that the work became very bitty towards the end of an epic and it was often difficult to keep the team busy. The problem was made worse by the fact we had different Product Owners across different epics. So the boundary of epics became a boundary for the Product Owner as well. The solution was simple. Stop planning around epics and instead plan at the task or story level. At this finer level of detail it is easier for the team to balance its work. For example, they would often mix the start of a new epic with the end of the previous epic. This allowed the team to be fully utilised and to transition cleanly between epics.

User stories are written from the point of view of the end user. An example user story might be something like: As a website user I would like to see important information on the homepage so that I find this site useful The types of information you show could be further detailed in the acceptance criteria for the story. These acceptance criteria would come out of a discussion with your Product Owner or Stakeholders. The task board tracks exactly the kind of information you mention. For example, you could have the following columns on your task board: Open In Design In Development In Test Done Each card will represent a story and the column it is in will indicate who is working on it.

In Scrum here is the rough breakdown: Epic - something so big it probably won't fit into a sprint, is not clearly understood in terms of customer requirements and should be broken down into stories. T-shirt sizing is a common way to size epics. Another way is to say we think it could take X to Y iterations to do this work. Epics are usually defined during initial product roadmapping and decomposed into stories in the product backlog as more is learned. Story - something actionable and small enough to fit in a sprint. These are story pointed and defined using INVEST criteria. Stories should deliver a vertical slice of functionality to the customer that is valuable and complete by the end of an iteration. Stories are usually created throughout product development, more so leading up to iteration planning and also during higher level product roadmapping. Tasks - decomposed parts of a story that get into HOW the story will be completed. Tasks can be hour estimated if desired. Tasks are usually defined by the people doing the work (developers, QA, etc), whereas stories and epics are generally created by the customer or the product owner representing the customer. Tasks are created within the bounds of an iteration because they are short-lived. There is very little value is tasking out stories that won't be worked on in the upcoming iteration.

You cannot have an SSO API without underlying user management, that's a dependency, you need to do user management first. Your story belongs to user management and should be done in that epic. Implementing the API so it supports the functionality may be another story alltogether in the SSO epic. So no a user story should not be associated with more than one epic.

I've built this a number of times in Excel. The easiest way I found to do this was to give each tasks (in your case: epic) a start and end date. (each task/epic in one row) Next, create columns for each day in the time span you want to cover. You can narrow them down to single character width. Give these columns a header row with all the dates (insert actual date values). In every cell of the matrix formed by the rows with your tasks/epics and the columns with all the dates, you need to implement the same formula, checking whether the date of the current column is greater than or equal to the rows start date whether the date of the current formula is smaller than or equal to the rows end date If the above hold true, give the cell a value of 1, otherwise 0. You can now, as a last step, apply conditional formatting to the entire matrix, coloring a cell if it has a value of 1 and setting text/background color to white if it has a value of 0. Voilà, you have your GANTT chart. You may want to add checks for empty values and weekdays/weekends and other exceptions. The formula may look something like this: =IF(OR(WEEKDAY([column date])=7;WEEKDAY([column date])=1);2;IF(ISBLANK([start date]);""IF(AND([start date]<=[column date];[end date]>=[column date]);1;0))) Everything in brackets (e.g., [column date]) are just placeholders for the actual cell references. If you want to only display your sprint names at the top of the "chart", you'll have to do some extra work, but that can probably be done by defining the start and end date per sprint sperately adding an extra row above the one with the column dates doing a lookup for each column for the name of the spring for the given date only showing the name when the same name is not contained yet in the cell to the left apply some formatting to make it all pretty That way, sprint names will only show to the left of a "stretch" - but at least it would be somewhat automated. Note that with this approach, one task/epic is always only ever in one dedicated row, so you will not be able to have the type of representation that you show in your sample, where you stack each sprint's lane dynamically. The above will create a waterfall (at least of you sort your records based on their start/end dates) and a lot of emtpy space. Anything else can only be done in Excel with VBA IMHO. If you're doing rather complex stuff or want to use this tool over a long period of time, you might want to reconsider doing this in Excel.

Make an effort to write independent smaller stories ...additional stories that she has no interest in nor does she understand. Don't write stories that the PO doesn't understand. If it is for developers' convenience, it is not a story. It is just a technical task. Put in more effort in writing smaller stories that the PO does understand. See previous discussion in PMSE here how to split larger stories. By the way, it is not that the Product Owner toils alone to write stories and acceptance criteria. In backlog refinement meetings, the development team should collaborate with the Product Owner to split the stories and write acceptance criteria. ...unit test suites for things that don't yet have a front end. Unit tests are for developer productivity. They can reduce the amount of regression testing to be done by the QA team. However, they are no substitutes for QA and PO doing acceptance tests from the end-user point of view. Stories should be vertical slices (with a front-end and a matching back-end). So my question is: do you see anything intrinsically wrong with this? Yes. Your team seems to be burdened by waterfall thinking. This is not unusual for teams trying to transition from waterfall to agile. Try to get some help (using online resources or a mentor) with slicing stories vertically. Your Engineering Manager seems to have the right instincts. That is a huge positive! How do you approach the testing of epic, etc? You don't. The team should put in the effort to write independent smaller stories that the PO can understand and test.

How do we manage small tasks and big ideas in the same list? In Jira Agile you can create epics to represent large stories. When you decompose this epic you can write several stories with the same epic as the parent. For smaller tasks, you can create sub-tasks under a story. ...manage one large website and a group of minisites/mobile apps. In the above situation, I will create 3 projects: Website Minisites Mobile Because you have a single team to do all these projects, you need a single Board. In JIRA/Agile when you create a Scrum Board, it can contain one or more projects. How should project boards, epics, stories and sub-tasks relate to milestones, versions, large features and small tasks? Fields such as the following are available in Jira: Affects Version/s Component/s Fix Version/s You can hide/show the fields, as needed, in the Field Configurations screen. When you create the stories/bugs, you can assign the Fix Version, for example. However, only add those fields that you are committed to maintain. When you are doing backlog refinement or Sprint Planning you will find that the Quick Filters are very useful to look at the subset of issues related to one topic. You can set up Quick Filters by Project, Version, Component and so on.

Start from the business goals you want to accomplish Story, epic and theme are not precise terms that are defined in a standard. If you search the Scrum Guide, you won't find any reference to these terms. See Mike Cohn's blog in response to similar questions - Story, epic and theme are merely terms we use to help simplify some discussions Scrum teams have. More importantly, you seem to be starting with an internal techie view of the project. You should start with what your site is intended to accomplish. As an example, let us say you have the following business goals: Get visitors to sign up for your email Newsletter. Get visitors to fill out a lead generation form to download a white paper. Get visitors to share your web site content on social media. Each of these can be written as an epic. Then each epic can be decomposed into stories. Themes, typically, are not part of this hierarchy. Let us say you apply some tags for your stories for convenience of discussing them together. You can think of a theme as all stories that have a common tag. For example, 'security' can be thought of as a theme. Then you can say something like, "Security is important, but I don't want to spend more than 20% of my project budget on security."

The Scrum Guide does not say anything about the backlog other than there is "items" in it. So consider the following my experience, not the official guide: The Product Owner should be able to decide whether something is an Epic, a Feature or a User Story. Because it's not about how complex it is or how long it takes, but what it is to the product. There is no hard rule that an Epic has to span multiple sprints. If all it's features' stories can be done in one sprint, that's great. And it does not make it less of an epic. A user story is basically a users interaction with the product. For example: "As a user I want to select a screen name from the list of online people to start a chat with them". A feature could be the ability to chat in general: "Users should be able to chat with each other". An epic might be the ability for users to interact: "The product should have a social component so users can interact". The decision is a business decision and your PO should be able to decide that from Epic down to User Story.

JIRA has several options for how you display swimlanes, one of which uses epics. You can change to a different type of swimlane if you want, or turn swimlanes off all together. The configuration for this is found under board settings. More details here.

This can be confusing because there is no authoritative body that sets terminology for Agile and, therefor, there is not "right" answer. But, these definitions and distinctions should be close. Roadmap The roadmap provides stakeholders with a view of how the product might roll out. Many teams do a planning that is longer out than a sprint but within about a quarter. The roadmap often indicates what major features are in that time period and their likely order. Though things change from sprint to sprint, this near-term period is the most likely to have minimal change. The roadmap then often describes the "next up" features. For a new bank teller application, it might look something like this: Q(n) Focus: Account History. Likely features: Account overviews, transaction history, transaction search, cross-account reference Q(n+1) Focus: Account Settings (details changes and switch account types) Q(n+2) Focus: New Account Creation Visually, this can take many formats. The right amount of detail would give stakeholders and idea of where a given feature might fit over the next year and no more. Product Release Plan This could be synonymous with roadmap. If so, use is as above. However, I've also heard this refer to a go-to-market strategy. This might actually be less detailed than the roadmap, if you can imagine. However, it would also have key market information in it. For example, if the first release would only serve customer segment X, my Product Release Plan would call that out and include information on how we reach out to those customers without confusing others. Then, when release 2 also incorporates customer segment Y, there will be new market strategy needs to loop in. In this case, this is a document used to coordinate efforts between teams and maybe whole departments. Minimum Viable Product (MVP) This term has a definition from The Lean Startup and is the smallest amount of work that must be done to learn something about your customer. These are incredibly small and usually delivered in a sprint or two (tops). However, the common use of the term does not match this definition. Instead, the common use of this term is the smallest amount of product that is viable in the market. This would be that first release from the release plan I mentioned. The real term for this is Minimum Marketable Featureset, but as I said, the common use of the term is all mixed up. As an example, if I were creating a streaming service like Netflix, a true MVP would be something that lets people simply go to a page and stream a movie - probably with a basic HTML tag. The goal here would be to see if people go to it and actually watch a movie online. (we take this for granted now, but when Netflix was created, a lot of people thought no one would watch movies online) An MMF would involve a small library of content, some sort of browsing, user accounts, and payments. These would be nowhere near as robust as we think of Netflix now, but they would be there.

"I'm creating epics off major components of the application. Is this the right way to frame them?" I would suggest framing the epics as functionality that can be delivered and tested in semi-isolation. Out of those you have mentioned : Research & Scenarios dont feel like epics to me: Research is a spike and documenting scenarios is part of the work to document epics Login Capability, My Fridge & Units of measure - These make sense to me as their own epics Food - Food research goes under the research spike. Assuming there's separate display/storage for Food (not the same as Fridge) I could see this being its own epic. Grocery list - This one feels like multiple epics. Storing & Displaying the Grocery list could be one, but sending the actual list could be a separate epic. I haven't gone into MVP, but as part of listing out your epics you should have a clear idea of what is absolutely necessary. If your goal is just storing groceries then login and sharing dont sound like MVP.

Whatever works for your team is just fine, of course. But there are a lot of considerations. First, VSTS (or Azure Boards, as it's called this year) doesn't naturally support the nesting of epics within epics. It may be possible to attach one through parent-child changes, but this will be a major pain. VSTS just isn't designed for the level of hierarchy you're imagining. To make your structure fit, I would change your "Release 1" epic into a Tag (that can be applied to any object in the hierarchy). If you are only using VSTS for backlog management, that will work. However, if your team is using Repos and Pipelines and all the other modern change management features of VSTS, you'll need to have one project per project (because they have separate code bases). In the end, my advice is to have one project per product. Over the long run, I suspect you'll run into enough problems that you'll end up having to do a painful migration later.