If you work with agile methodologies, you’ve surely heard about epics. Epics are hard to define, because there isn’t an official definition, and if you ask around you’ll see that not everyone shares a unique idea of what an epic is. But if you watch how people use epics you can get a clue about them.
Named after this amazing stellar plant that hails from the northernmost part of the Northern Hemisphere. Stellaria takes their name from the stars in the boreal sky that they resemble. And so it is with this, our newest, biggest-ever new Epic release: star-filled with shiny features that will make your mind glow!
Projects, software or otherwise suffer from the common problem of miscommunication. While the client expects something else, the product owner has a different understanding. Then there are developers who at times have different understanding of work to be done. With Agile, many of such concerns are addressed, thanks to daily standups and clear goals set before a sprint. Still there are some areas that are generally looked upon during the beginning of the project and are only relevant when sprints approach completion. One of those is the clear difference between done criteria and the ready criteria. Generally people use these terms interchangeably causing avoidable confusion. In this post, I will try to clear the air on the definition of done and the definition of ready.
We’re always in pursuit of the best tool or technique or methodology that we think will almost magically set us on the path to be super productive, super fast and super cool people who can fix bugs in minutes if not seconds, who can estimate stuff correct upto two decimal places and who can foresee any possible upcoming roadblocks. But, till that happens, we’ll have to make use of the current tools and techniques. Kanban vs scrum, and how to choose between them, seems like the battle these days.
So named after the magnificent king of the Taiga, the Black Bear, which the Native American Indians considered a symbol for the free spirit; surely something we can all aspire to become!
To celebrate beautiful hairy things, we've name Taiga 2.0 the Pulsatilla Patens release, named after this beautiful purple, slightly hairy flower native to Europe, Russia, Mongolia, China, Canada and the United States. And why not? It's been hairy getting to 2.0, but it is indeed beautiful (code).
Your Award-winning Open Source Agile Project Management tool has a new release Taiga 1.10, which we named Dryas Octopetala after a gorgeous small plant living in the arctic Taiga.
Though they sound similar in a functional manner, user stories and tasks are quite different aspects of agile methodology. Still, many of us use the terms user story and tasks interchangeably. Not only this causes confusion, but also keeps you from reaping the full benefits of your agile work culture. Until and unless you clearly know the terms and their meanings, you will not be able to follow the best practices. So, let’s try to clearly understand the difference between user stories and tasks.
Filing bugs is a mundane task - everyone does it, from developers to testers, and sometimes even the end users. But many of us don’t understand one of the most important concepts while filing a bug, the difference between priority and severity. While some use these terms interchangeably, others use them with opposite meaning. Let us today clear the misconceptions about these two terms, so that teams can make the full use of their bug management tools.
I am writing this post at 39.000 feet on my way back from London to Madrid. Yesterday was a great day for Taiga but most importantly, we had so much fun! So there is this thing called Agile Awards in the UK. It has been going on for 7-8 years now and the different categories acknowledge various aspects of the Agile movement. Projects, people, initiatives... and for the first time this year, they added the Best Agile Tool award.