Many companies are acknowledging the advantages of using Open Source software. One of the main characteristics in open source is that it can accelerate processes of innovation.
It's no longer a matter of cloud versus non-cloud. On-demand, flexible and elastic resources are now the norm. What does remain is the question regarding how you operate a platform like Taiga which deals with your organisation's projects and users.
It is really amazing the community we have all managed to gather around Taiga.io and open source in general. Highly qualified professionals that share their time and knowledge to help each other fulfill their aspirations with their projects. It is truly inspiring what we all can do when we are surrounded by a positive, productive community. That is why we are launching a series of articles that will showcase people and ideas that have been critical to Taiga.io and its journey.
Kanban has meant a breakthrough for many teams that used methodologies like Waterfall or Scrum. Their differences and similarities have been a topic of discussion for many agile project management experts and their teams. This subject has already been tackled in this blog but today it is worthwhile sharing the magnificent conference at Talks at Google by Eric Brechner.
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.
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.
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.
How do you guarantee your QA? How do you currently perform this role in your team? Today we have an interesting and motivating agile practice… Very successful for our teams... Read this one carefully!