How to Avoid the Jira Black Hole
Many software development teams use Jira these days to manage their work items. Software development teams create Jira issues like epics, stories, tasks, or bugs and shoot them through their Jira workflows. The issues run through sprint and Kanban boards, and once they are done — or resolved —they are gone and forgotten.
It’s like the issues are being sucked into a black hole. Consequently, I call it the Jira Black Hole.
Everything is fine at the beginning of the development of many software products. But the longer a software product gets developed, the more problems occur because the Jira Black Hole does not reveal any information it has previously consumed.
The problems start when the product gets more extensive and complicated, people leave, or the team is getting scaled up. Then, product owners, developers, and other stakeholders start to ask questions like, “What was the process like we implemented two years ago?”, “Why is the product doing it that way?” or “How can we test it?”
Since I see many teams facing and running into the same problems repeatedly, let me provide an approach to how you can avoid being sucked into the Jira Black Hole.
The Basics
The key to the approach is that it is lightweight and sustainable. Because only if it is as lightweight as possible, people will follow the approach. And only when people are following, the approach can be sustainable. Thus the set of practices I recommend are the following:
- Onepager
Short wiki pages where you write a summary in prose of what the need of the user or requestor is about and why they want it. You also link all related information here. - Scribbles, Wireframes, and Domain Story-Telling
Create easy-to-understand visuals to explore user interaction and system communication. It helps you to understand your domain better. - User Story Mapping
Use user story maps as the joint of all your doing. You explore the details of your domain, and it allows you to use your Jira issues as living documentation. - Writing Effective User Stories
Use a refined Connextra template for user stories. Use a specification by example approach for writing acceptance criteria following Behavior-driven Development (BDD). - Mature Epic Handling
Use the Jira issue type Epic for packaging existing user stories instead of using epics as large user stories, which are then broken down. Track epics using a combination of Kanban and GANTT-like roadmaps. - Clean Code and Domain-Driven Design
Write and structure your code in a way that is understandable and reflects the given domain.[1]
As for the toolset, I refer to digital tools only. Of course, I also like having a physical whiteboard and sticky notes. But since I work with globally distributed teams a lot, and since many people work from home due to the Corona pandemic, I focus on the following tools providing a fully digital approach.
- Atlassian Jira
A no-brainer — this is why I am writing this article. Jira acts for holding issues and processing them following a given workflow. - Atlassian Confluence
I am a big fan of this wiki software and especially of the use of its (standard) macros. And, of course, it’s integrating with Jira like a charm. - Miro
My online whiteboard tool of choice. A whiteboard tool gives you many degrees of freedom to arrange information intuitively.
And that’s already it. You don’t need more tools or fancy plugins to create lightweight and sustainable documentation to avoid the Jira Black Hole!
Onepager
So tell me what you want, what you really, really want!
Wannabe, Spice Girls
A onepager is a single wiki page covering all essential information about a topic and providing links to further information. Thus it allows you to dive into a specific domain quickly. The ultimate and first goal of a onepager is to lower the entry barrier as much as possible to get started.
Remember that you must onboard new people when they join your development team. They are interested in what the product is about, and they need to find the correct information. Therefore, use prose to write down the WHAT and the WHY. What is the problem that your product should solve, and why should this problem be solved?
Also, add some surrounding information that gives context. For instance, if you create a set of features for a specific customer in a B2B software product, also provide some information about the customer. It helps people to relate more to what they are doing.
Be aware that most inexperienced people always start to solutionize right from the start. That is precisely NOT what a onepager should be used for. You create a onepager to do the first step toward common understanding and collective alignment on the problem and the domain — not its solution. Thus, the second goal of a onepager is to open up the space for ideas.
A onepager is a living document where you constantly add, refine, and link information. This provides context, which helps people to understand your product and reduces frustration.
Therefore, onepagers provide a basic introduction to a given domain and link to other artifacts created for its implementation. I differentiate between onepagers for product areas and technical initiatives.
Product Areas
In line with the requirement areas of Large-Scale Scrum (LeSS)[2], a product area is a cluster of functionality that can be distinguished from other clusters of functionality. For example, if your product is a webshop, your product areas may be something like user account, article search, detail page, purchase, and fulfillment.
Whenever I create certain page types in Confluence — like the onepager for product areas — I create a page template and an overview page with a search field, a page property report table, and a description of the page statuses.[3] Below that overview page, all the onepagers get created.
Looking at the statuses, you see that a product area cannot be DONE but is either ACTIVE or OBSOLETE. That is because your product and its underlying product areas may be constantly changed or expanded. Product areas are a vital thing on which you are continually working. Therefore, a product area can only become OBSOLETE but is never DONE.
The image above shows the onepager for a given product area. You see that there is a rough description of its contents. You can also see that already two work package epics are listed.
In the page properties table, you also see a link to a Miro board — more precisely, to a frame of a Miro board. Inside this frame, you will collect all scribbles, diagrams, and most importantly, your user story map.
Technical Initiatives
A technical initiative is for example a larger refactoring of code or a migration to a new version of a framework you are using. Inside technical initiatives, try to avoid working with user stories. It’s more about working on tasks since you are not working on the functionality of the product. Thus, if you add user stories to a technical initiative, the chance is high that you are mixing up an initiative with working on a product area.
Of course, there’s an overview page for technical initiatives. It is similar to the product area overview page. However, the onepager itself looks a little different.
I prefer to describe the GOAL that should be reached instead of the WHAT. It is because a technical initiative starts and ends at a particular time. The page status also represents this circumstance by using the statuses DONE and REJECTED instead of ACTIVE and OBSOLETE.
Additionally, I always provide one section called Further Information. You can use it to describe the details of the technical initiative or to document some information directly on that page.
Remember, you may use these pages in the future to look at what has been done and why. Also, the page properties table holds the date when a onepager has been closed. The created date of the page and the page history gives you the information when it got ideated. The work packages provide the information when the development team worked on it. And the closed date tells you when you and your team finally set the initiative to DONE or rejected it.
However, since I don’t want to overextend this article, the following descriptions focus on working on product areas only.
Scribbles and Domain Story-Telling
After creating the onepager, it’s time to enter the ideation and solutionizing phase. It goes a little bit in the direction of the five stages of the design thinking process, but I don’t differentiate the phases too much.
The next step for having an excellent start to dive into a domain or describe new features is to organize workshops with stakeholders like UX designers and UI designers — and of course, end-users. It’s always a great idea to start by discussing the WHY together with the stakeholders — you may use the onepager for that.
Wireframes
At a certain point in time, you may feel that the WHY is almost clear, and you want to define the WHAT in more detail. Then, having some scribbles and wireframes in place helps everyone to create a shared understanding of what should be implemented later on.
The above picture shows the login screen scribbled using a wireframe in Miro. I find Miro’s functionality for creating wireframes sufficient here. You should not make a 100% mock of your product at this point since you will experience changes when diving deeper into the domain, so any additional time invested is a waste.[4]
Diagrams and Modeling Languages
Wireframes are one thing. And I find them sufficient for many products like small or simple webshops where the processes behind them are clear. However, there are products where you are moving in a more complicated or even complex domain. Then, you should give diagrams and modeling languages a try.
At the beginning of my career, I used UML[5], BPMN[6], or eEPC[7] for that. It is what I’ve learned at the university and during my IREB requirements engineering seminars.[8] Thus, I used UML use case diagrams and activity diagrams a lot and combined them with requirements statements following a sentence template.
However, most stakeholders do not understand the notation of UML or BPMN diagrams since they do not use them regularly. Therefore, it is worth considering a more intuitive and lightweight approach. Domain Storytelling (DST) is such an approach since it is very near to natural language.[9]
I find DST diagrams — or domain stories — as a fruitful combination of UML activity diagrams and use case diagrams. Domain stories contain a set of actors, activities, and work objects. The actors in the above diagram are User and Webshop. Activities are illustrated using arrows. Work objects are Login Credentials and Welcome Page.
You can see that each arrow that originates from an actor holds a number. It means you can read the whole story by simply following the sequence of those numbers. For this example, the above domain story consists of three sentences in the following order.
- User enters login credentials to Webshop
- Webshop validates Login Credentials
- Webshop displays Welcome Page to User
Of course, this is only an oversimplified example that only hints at the advantages of the method.
There are also weaknesses of DST. For instance, there are no decision nodes, like diamonds in UML and BPMN. For example, what happens if the credentials are invalid? In this case, you have to use comments to clarify which way to go or draw separate domain stories.
However, I must say that I managed a lot to be modeled using DST. I find that the advantages outweigh because you can sketch the interaction of users and (multiple) systems easily and quickly — it’s really lightweight. And since we define details when we create user story maps and write user stories, you do not need to invest too much effort in creating a comprehensive, fully blown BPMN diagram with all the details upfront.
Diagramming with Stakeholders
Same as for working on scribbles and wireframes, it’s always a good idea to set up workshops with stakeholders like the requestor, end-users, domain experts, and developers of your team. The illustration of the process should be a collaborative effort that helps all involved parties to create a shared understanding of the domain — and DST is a great tool for that. Discussions will automatically come up. Thus, the very purpose of these diagrams is to have directed discussions that generate a common understanding.
Whenever you create such diagrams, you should also add them to Miro at the very place where you add further information like the wireframes and, of course, the user story maps. Thus, let’s continue with user story maps.
User Story Mapping
In the above picture, you see an example user story map where it’s surrounded by all related information. Very important, this map does not say anything about epics yet. At this point, it just contains potential future user stories in its body.
I recommend that you don’t restrict yourself to epics when working out a functional domain. Just work with the user story map since it is a more visual way that helps you to ideate. The creation of epics can come later, and a user story map allows you to out-scope or in-scope something at any time.
Fill in the Gaps
[…] scope doesn’t creep; understanding grows.
Jeff Patton, User Story Mapping
Use the user story map for further ideation and reflection on the domain. It’s often said that a user story is an invitation for conversation, following the 3C’s for user stories — card, conversation, confirmation.[10] Consequently, you can regard a user story map as a long conversation that enables you to reflect on the bigger picture to make it blossom by filling in the gaps.
User story maps are not a static tool. They change over time so that you find new steps and identify more details. You reorder them to make them more intuitive and meaningful. All of this work helps you and your team to constantly reflect on what you are working on.
Color-Coding
One great thing about user story maps is that you can colorize the cards. You can think of whatever you want to indicate. I propose (at least) the following coloring:
- Green for stories that are done
Whenever you resolve a story inside Jira, set the color of the respective card to green.[11] - Yellow for stories that need to be reworked
Whenever you say that you want to make changes to an already implemented story, mark it yellow. - Red for stories that should be removed from the product
If you want to remove an existing feature or functionality from your product, mark the relevant stories red.
Colorization helps you to get an instant overview of what is going on. Also, think about the good feeling when your user story map becomes more and more green. It has a motivating effect.
However, I recommend not using color-coding to actively track which stories are in process, blocked, or any other process steps like testing, etc. Since you are (currently) unable to automate this coloring, keep in mind that it comes at a certain effort. And don’t forget that Jira does an excellent job using sprint or Kanban boards to visualize progress.
Do Not Use Jira Plugins
Of course, there are Jira plugins available for user story mapping — like Easy Agile User Story Maps.[12] However, I recommend using a whiteboard or whiteboard tool like Miro that gives you more degrees of freedom. Namely, I see the following three disadvantages of using a Jira plugin.
The first disadvantage is that user story maps inside Jira are isolated. I always liked about (physical) user story maps that you can hang related information directly around the story map like scribbled screens or diagrams and charts. By doing so, you immediately get a better idea of what a user story map is about and have better conversations around it. You are just so much more creative when using a whiteboard!
The second disadvantage is that all of the plugins I know use epics for the backbone — meaning the narrative flow of tasks below the activities. It does not allow to get the maximum out of epics. I will discuss this later in this article.
The third disadvantage is that you are directly creating Jira issues. When I start a user story map, I want to play around with it. I want to move things around, remove cards, add them, remove them again, rewrite them, and so on. When directly dealing with Jira issues, such things become unnecessarily complicated.
Thus I recommend first creating a user story map that only holds titles on the cards — at best short verb sentences like ‘Enter username.’ And when you and your team have the feeling that your story map somehow is in good shape, only then has the time come to start writing stories inside Jira.
Writing Effective User Stories
Now that you have a good feeling about your user story map, you should start creating issues inside Jira.
It was at that moment that I learned that the word requirements actually means shut up. For a great many people, that’s exactly what requirements do.
Jeff Patton, User Story Mapping
As Jeff Patton put it in the above quote, today, we learned that it is not our goal just to write down an accurate requirement statement. Instead, following the Manifesto for Agile Software Development[13], we now try to foster shared understanding by communication to achieve a better outcome.
Make Use of Templates
However, good practices from traditional requirements engineering are still valid when writing user stories. For example, always use active voice when writing things down. Active voice forces us to be more precise, for instance, by clearly stating the actor.
One prominent method of traditional requirements engineering is using sentence templates for requirement statements.[14] Indeed, the well-known Connextra Template of user stories is a sentence template. And it forces us to use active voice. And by doing so, the template helps us foster better communication.
Let me state the Connextra template for completeness.
AS A <type of user: who has a need?>
I WANT TO <user need: what is the need?>
SO THAT I <user value: why do they have the need?>
However, even though it’s a template, I often see that teams write user stories without stating the user value. Thus I recommend using the following refined template, putting the value first. Therefore, start with defining the value and only then define the user and their need.
IN ORDER TO <user value>
AS A <type of user>
I WANT TO <user need>
INVEST in Smaller User Stories
When you recall my user stories for the login screen, there was one story for each input field. Most people think this is overhead, but I have a point here. Taking a look at the INVEST Framework for user stories[15]— Independent, Negotiable, Valuable, Estimable, Small, and Testable — I focus on small.
Small items are better testable since you have a reduced scope. A user story with an endless list of acceptance criteria is a chore for every developer. Thus, the quality of its implementation and, of course, its testing will suffer due to the fatigue of the testers.
Small items are also better estimable. Since the implementation effort of a user story is not growing linear, but exponentially, the chance is high that your estimates become more inaccurate the larger your items are. Thus, you should do your best to slice them down as much as possible when, for example, relying on story points.
Even when you do not do estimations with a flow-oriented approach like Kanban, smaller items help you reach better predictability when doing probabilistic forecasting.[16] Since you are able to work off more items faster due to their reduced cycle time, the effect of the law of large numbers[17] kicks in sooner so that your cycle time distribution stabilizes faster. It means that you can take a shorter period for the historical data on which your predictions are based.
And now comes the trick: Negotiable and Valuable are handled by the user story map. Keep in mind that you not only have discussions on single user stories, but you can also have them based on your whole map. And this allows you to slice and cut your stories as small as possible.
Specification by Example
I have seen many teams writing endless bullet point lists when defining acceptance criteria. However, also at this point, I recommend using the following template originating from behavioral-driven development (BDD), also known as behavioral specifications or specification by example.[18]
SCENARIO: <title>
GIVEN: <initial context>
WHEN: <triggering event>
THEN: <expected outcome>
See an example of its use in the image below. Please note the use of active voice. For instance, instead of writing “THEN a session has been created,” I write “THEN the webshop creates a valid session for me.” Since the webshop performs this action, I name the webshop by using active voice. It always ensures that I make clear who is doing what — subject, predicate, and object!
This template nudges you immediately to edge cases. When I see the two scenarios above, I directly ask myself what’s happening when the username or password is incorrect? How is ‘username’ defined — must it be a valid email address, or can it be just a random string? So when you write and discuss these scenarios with your team and stakeholders, it’s always a very fruitful way of working. And the writing of the scenarios ensures that all involved parties have the same understanding.
In addition, you get a perfect feeling of when to split a user story even further. Sometimes you see that you can cluster specific scenarios. Sometimes, you stumble upon scenarios where you immediately find that a dedicated user story must cover this. Thus, this format also supports you in having small user stories.
Another advantage of this way of writing acceptance criteria is that the Testability of user stories is highly increased. When doing manual testing, the scenarios provide way better information than bullet-point lists. And you are also able to do fancy test automation, for example, by using Gherkin and Cucumber.[19]
A Collaborative Approach
Keep in mind, whenever you are writing user stories, it’s best to do this at least as a pair, in a three amigos session, or a mob with the whole team.[20] The traditional way of writing requirements lists and specification documents often used to be that the requirements engineer was working on a Word document or Excel list — primarily alone. And that’s not what the writing of user stories is about nowadays.
Instead, writing user stories is a practice to foster collaboration and communication and direct it towards a final agreement. Again, this is ideally about the 3 C’s of user stories.
- Card
Work out your user story map by putting cards on it that only hold a short verb phrase title. - Conversation
Have a fruitful collaboration and conversation when writing the user stories by formulating the (refined) Connextra template inside a Jira issue. - Confirmation
Collaboratively discuss the acceptance criteria. It brings the user stories to a state where the developers say they can start developing.
You May Estimate
Even though the #NoEstimates movement became quite popular[21], we should consider the real purpose of estimations. The first thing to say is that you have estimates, not ‘exactimates.’ Thus, I think the actual value of estimation sessions like planning poker is not to have the most exact story point value.
The real purpose of such sessions lies in the following. First, you can foster your communication around user stories even more. The estimation is the last step of the 3 C’s confirmation. It means that when everyone agrees on the effort required by a user story, the chance is high that everyone has the same understanding.
Second, and ironically, your Kanban system may profit from estimating even though you do not use the estimates for your planning and forecasting. When estimating, you have the chance to identify large items. Thus, you can take these items and slice them down. As I said before, smaller items may support the stability of your cycle time distribution.
Linking User Story Maps with Jira Issues
Whenever you create and write a user story inside Jira, link it with the card of your user story map. I also add the issue key on the card, which is sometimes helpful. However, you can also link using the title.
You now have the high-level overview with all surrounding details inside and around your user story map on your whiteboard. In addition, you can use this board to deep dive into the details by clicking on the link that opens the respective user story that holds the more detailed information.
The Jira issue contains the formulated Connextra template, the acceptance criteria, links to other issues, links to epics, and links to your code repository, like Git. You may also use a tool like Xray[22] or TestRail[23], where you manage your tests. Thus you have end-to-end visibility on all your artifacts.
And the best thing: all these are living artifacts. So your documentation grows, shrinks, and changes, driven by the actual development work. And exactly this is what I mean when talking about lightweight and sustainable documentation.
Traceability
In traditional requirements engineering, one of the requirements management disciplines is called requirements traceability. It means you can trace back all changes that occurred in the context of a given requirement.
Apart from traditional requirements engineering, from time to time, it happens that you need to rework or refactor a given user story. What you can do now is the following:
- Clone the user story inside Jira and refine the description of the new user story
- Colorize the card on your user story map so that it is clear that it needs to be reworked — I use the color orange for that
- Link the new user story to the card on the user story map
- When the new user story is done, colorize the card to indicate that it is done —I use the color green
And that’s it. Now your user story map links to the current user story inside Jira. And when you open this user story in Jira, you see it’s a clone of another user story. Thus you can click on the issue link to see what the previous user story was about. And so, you have a history of how your product changed over time.
Of course, you can set up a custom issue link type inside Jira to make it more explicit which issues have been reworked. However, since I want to keep it as lightweight as possible, I leave it to the combination of clones/is cloned by. I don’t want to have the extra effort of manually editing the issue links whenever I want to rework a user story.
Mature Use of Epics
I prefer using epics as work packages instead of large user stories that are broken down. In short, you create the epic after you create the user stories. Take a look at the image below. There you see how user story mapping supports you whit it.
First, you create the user story map, including that you create the stories inside Jira and link them with the user story map. Then take the user story map and make up your mind about which stories you need to create a meaningful yet small as possible work package.
Thus, we do not need to invest much time into the upfront definition of epics with an artificial Connextra template and endless lists of acceptance criteria. We replace it with the more visual approach of user story mapping. We draw an imaginary line around the stories we want to pick for a particular work package and add them to the epic. Done.
The advantage of these work packages is that they are done at a certain point in time. It allows you to use them with a Kanban system where you can coordinate what you are working on simultaneously. My article A Scrum-like Multi-level Kanban Implementation provides a more detailed description.
However, see an example for a work package epic below.
Add Work Packages to Onepagers
I’d like to list the epics manually on the onepager because then I have the issue link ‘mentioned in’ inside the epic. Thus there is a bidirectional connection between the epic and the onepager. However, you can also use a JQL query that asks for a defined label.
By listing the work packages, your onepager becomes an entry point to Jira, and it is clear which work packages stand in the context of a given product area. It may be the case that you list a work package on two or more product area onepagers if a work package touches multiple product areas. However, I think it is a good practice to keep the work packages as small as possible. A work package that touches multiple product areas may be a sign of a poorly composed and designed work package.
Use Roadmaps for Planning
The roadmap feature of Jira is ideal for planning the sequence of your work packages. When you are using Kanban for coordinating work packages, you may use probabilistic forecasting to set delivery dates of the work packages. It gives you an excellent and easy-to-maintain visual representation of your plan.
Plans are nothing; planning is everything.
Dwight D. Eisenhower
However, I see these roadmaps in line with Eisenhower’s statement. A roadmap is a tool for continuous planning. That means it underlies constant changes — this is often misunderstood. Therefore, always be careful to communicate such a GANTT-style roadmap to stakeholders. In most cases, it leads to artificial expectations and unrealistic due dates. In the end, everyone lies to each other about delivery dates, and the whole communication degenerates into a mere business theater.
Therefore: use the roadmap for your own planning and only communicate it to stakeholders with whom you have a collaborative work relationship.
Never Estimate Epics!
And here comes one essential piece of advice: NEVER even consider estimating work package epics! Whatever estimation method you choose, you will ultimately fail since work packages are large objects where you have many unknowns.
Also, keep in mind that story points are about pure effort. The cycle time is independent of that effort since issues are usually idle a lot. For instance, the metric flow efficiency describes it very well.[24] Therefore, and especially, it’s always a bad idea to sum up the story points of the stories contained in a work package and make a due date out of it.
And one thing in addition: most of the time, you don’t even know when you start with a given work package. Consequently, plans are nothing, and planning is everything.
Conclusion
Since this is quite a long article, let us recall the practices I presented.
- Create onepager
- Story mapping + scribbles and diagrams
- Write user stories + link Jira issues with cards on the user story map
- Package user stories using epics
- Plan the sequence of work packages (epics)
- Repeat, refine, redo — whenever it is necessary
Keep in mind that all of this requires competence. It’s one thing to read this article and try to follow it. However, competence also grows from experience. Thus you can only become a master by trying it out and practicing it for a certain time.
And of course, even though this approach tries to be as lightweight as possible, it still requires a disciplined way of working. You need to be disciplined when writing user stories. You need the discipline to fill out and update your onepagers. You need the discipline to colorize your cards in your user story maps. And so on, and so on. None of this happens by itself — unless you found a way to automate it.
Therefore, keep an eye on how disciplined you are. Also, investigate which environmental and organizational factors harm your discipline. However, in the short run, the presented approach may seem to be an overhead. But in the long run, the disciplin pays off. You will keep the methodological debt at a low level so that you are able to keep control over your product.
And as I said at the beginning of this article, I have seen too many teams facing the same problems. So don’t let you get sucked into the Jira Black Hole.
Footnotes
[1] However, I leave the topics of Clean Code and Domain-Driven Design (DDD) to the experts since I am not a programmer (anymore) and not a Clean Code or DDD coach. Instead, as a former requirements engineer, product owner, and agile coach, this article focuses on how to work with user stories so that Jira does not mutate into a black hole. However, I added Clean Code and DDD for completeness since it allows you to use the code as efficient documentation.
[2] Learn more about the Large-Scale Scrum framework (LeSS) and requirement areas.
[3] The macros used on these pages are status macro, create from template macro, excerpt macro, excerpt include macro, include page macro, livesearch macro, page properties macro, page properties report macro, expand macro, and info/tip/warning/note macro.
[4] I chose a simple example for this article not to overcomplicate things. It may look artificial at some point. However, I worked with highly complex and complicated environments where this approach worked out.
[5] UML stands for Unified Modeling Language. Learn more about it at Wikipedia.
[6] BPMN stands for Business Process Model and Notation. Learn more about it at Wikipedia.
[7] eEPC stands for extended Event-driven Process Chain. Learn more about it at Wikipedia.
[8] IREB stands for International Requirements Engineering Board. Visit ireb.org to learn more.
[9] Domain Storytelling (DST) is a lightweight approach for collaborative modeling. Read the article WPS Collaborative Modeling or watch this video on YoutTube to learn more about it.
[10] Learn more about the 3 C’s for user stories at Agile Alliance.
[11] Of course, it would be great if the coloring of cards in user story maps were automated. It would also be great to have a bidirectional linking between Jira and Miro’s user story maps.
[12] Find the plugin Easy Agile User Story Maps on the Atlassian Marketplace. Of course, it’s a good plugin. However, I prefer to use a whiteboard with all its possibilities.
[13] Learn about the Manifesto for Agile Software Development.
[14] For learning about requirements templates, you may read this book excerpt by Chriss Rupp.
[15] Learn about the INVEST framework — Independent, Negotiable, Valuable, Estimable, Small, and Testable — at Wikipedia.
[16] Watch this video on YouTube to learn more about probabilistic forecasting.
[17] Learn more about the law of large numbers at Wikipedia.
[18] Learn more about Behavior-driven Development (BDD) at Wikipedia.
[19] Read the article Writing better user stories with Gherkin and Cucumber.
[20] Learn about the three amigos at Agile Alliance.
[21] You may read Ron Jeffries’ article to learn more about #NoEstimates. You may also follow the discussion on Twitter.
[22] Xray is a Jira plugin that allows you native test management in Jira. I consider it the best test management plugin for Jira.
[23] TestRail is an excellent test management standalone tool that can be linked with Jira.
[24] Read this article at Nave to learn about flow efficiency.
Related Medium Articles
Collaborative Modeling: Domain Storytelling as a Catalyst for Product Backlogs
Carsten Lill, Nils Hyoma
User Story Mapping — Part 1
Krisztina Szerovay
User Story Mapping — Part 2
Krisztina Szerovay
Competence and Discipline: The Pillars of Excellence
Boris Karl Schlein
About Competence, Discipline, and Methodological Debt
Boris Karl Schlein
A Scrum-like Multi-level Kanban Implementation
Boris Karl Schlein
Book Recommendations
User Story Mapping: Discover the Whole Story, Build the Right Product
Jeff Patton
Large-Scale Scrum: More with LeSS
Craig Larman
Extreme Programming Explained: Embrace the Change
Kent Beck, Cynthia Andres
Clean Code: A Handbook of Agile Software Craftsmanship
Robert C. Martin
User Stories Applied: For Agile Software Development
Mike Cohn
Agile Estimation and Planning
Mike Cohn
Domain Storytelling: A Collaborative, Visual, and Agile Way to Build Domain-Driven Software
Stefan Hofer, Henning Schwentner
Specification by Example: How Successful Teams Deliver the Right Software
Gojko Adzic
Fifty Quick Ideas to Improve Your User Stories
Gojko Adzic, David Evans
Requirements Engineering Fundamentals
Chris Rupp, Klaus Pohl
