Do You Find Agile Epics a Fuzzy Concept? Here’s A Guide.

/0 Comments/in /by

Do You Find Agile Epics a Fuzzy Concept? Here’s Your Cheat Sheet

For many it might seem that Agile has some pretty confusing and frankly odd terminology. If you feel included in this group, let us give you a hand. In this article we give you some clarity regarding some of the methodology’s essential terms, in this case, Agile epics.

What Is An Agile Epic?

Essentially, the term user stories means requests from users regarding a given product. Though ’requests’ might not exactly be the best word to describe them, think of each as a small unit of functionality. Let’s say you are developing an app that is basically a map. One story could be a feature that allows users to calculate the optimal route between multiple points on the map, while, if your company offers trips abroad, another may be utilized for arranging accommodation. Stories are basically sub-tasks within a larger, more comprehensive unit.

You probably guessed it right, this larger unit is what’s called an epic. Within that, epic stories are related to each other as they are all pointing towards the same goal. Agile often works with independent yet connected teams, meaning each team can have their own Agile epics. These large chunks of work are parts of initiatives, which are the sub-groups of themes, which could be considered as a kind of overarching goal of the company.

Related: Agile QuickTip: User Stories and Product Ideas Should be Born on Index Cards

What’s The Benefit Of Agile Epics?

To put it shortly, clearly defined objectives and priorities. Agile is about continuous improvement and catering to customers’ needs. Large pieces of work and their smaller units help you exactly with that, giving your team a clear picture of the direction you need to go.

Another benefit is simply organization. A final product could be insanely complex, meaning there are plenty of small units of work to be taken care of. Stories that are more closely related to one another should be included in a category one level above them, and that’s where their epic counterparts enter the picture.

Last but not least, your time management might see some improvement. Agile epics contribute to planning sprints more effectively, thus giving your team a better estimate of how long the project is going to take. They are a great item in the toolbox that could be real game-changers.

Skipping Scrum Retrospective Meetings? You May Want to Reconsider

/0 Comments/in /by

Scrum Retrospective Meetings – To Keep It Or Leave It?

How many times have you heard or said that retrospectives are useless? Project management can mean that we deal with problems on the go; so why waste our time? Guess what. Retrospective meetings are not about solving problems. Let us explain.

First, take a look at the Agile Manifesto, namely its 12th principle.

’At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.’

Noticed there’s no mentioning of any ’problems’ in there? Retrospective meetings are indeed the most widespread ways that support this principle, during which team members discuss how they can improve on operations. Obviously, if there are problems concerning daily tasks, by definition they hinder effective work; therefore, solving them is a pre-requisite for development. It’s a pre-requisite, not an end goal.

Very simply put, the goal of a sprint retrospective meeting is to improve and create efficiency throughout the product dev and release processes for the upcoming sprints. Development teams achieve this by discussing what went well and what did not during the previous sprint. In this way, an  inspect and adapt mindset is leveraged during sprint reviews and helps in the way of continuous improvement.

It All Boils Down To Concentration

Dealing with problems on the way is good indeed, so much so that postponing a problem until the retrospective meetings is a huge mistake. But why do scrum teams need to dedicate a separate ceremony to development itself, why can’t we just do that underway? The word you’re looking for is focus…

During ongoing projects, one must pay attention to opportunities for fixing issues; however, if there’s no dedicated time for that, these will simply get lost in the sea of urgent matters. Time presses us to solve things ASAP, meaning we tend to think in short-term solutions, creating just as much value as we possibly can in that short period of time.

Related: Agile QuickTip: Vegas-Style Retrospective

If we focus on and dedicate time to issues hindering us, however, we can create maximum value as per our creativity and individual talents. Additionally, this way we plan for the long-term, allowing us to enjoy the benefits of solutions we come up with much longer. A long-lasting reward for a short period of time spent on it. It’s not too hard to realize that long-term value outperforms clumsy, short-term solutions.

Final Thoughts On Retrospective Meetings

To sum it up, we need to keep dealing with problems constantly, but this cannot replace retrospective meetings. Smaller, menial problems could wait until the ceremony, but keep in mind that having no issues is the beginning of development, not its final goal.

To add to the myriad of benefits scrum retrospectives have for the scrum team is included its reputation in building consensus among development team members.

Ponder about it. Do you hold retrospectives with the above mindset? Do you even care to hold it? If not, are you aware that having no retrospective goes right against the definition of Agile and the scrum framework, as well as continuous adaptation and development?

How To Conduct a SWOT Analysis in Agile

/0 Comments/in /by

The WHYs and HOWs of Agile SWOT Analysis

A common mistake during switching to Agile is that an organization throws the baby out with the bathwater, discarding business strategy, values and practices that have benefited them so far. In order to avoid this, a SWOT analysis might come in handy.

Though used in traditional management, SWOT analyses in Agile is equally beneficial and advised. Using it properly can help prevent this mistake.

What is a SWOT analysis?

Coined by Albert Humphrey in the 1960s, the term SWOT analysis is an easy-to-understand tool for strategic business planning, used often in traditional ways of management; often prior to but also during decision making. SWOT stands for Strengths, Weaknesses, Opportunities and Threats. The goal of the SWOT framework is to identify internal and external factors that could help or hinder the organization in achieving its goals, be it on the project level or above, business operations, competitive advantage or other area.

Internal factors:

  • Strengths
  • Weaknesses

External factors:

  • Opportunities
  • Threats

Results are summarized using the SWOT matrix.

You might also be interested in: For High-Definition Planning, Plan Sprints Backward

How to conduct a SWOT analysis?

The two main steps are analysis and decision making/planning.

The main and most difficult objective of performing a SWOT analysis is mapping out the whole situation as accurately as possible. Practically there’s just no way to identify every single strength, weakness etc., so here’s a couple of tips that could help.

Define the objective as clearly as possible: Categories used by SWOT are too general; they need to be narrowed down.

Start with the external factors: Market factors can determine whether something should be considered a strength or weakness. Start by asking “what opportunities and threats exist?”

Extensive participation: Creating a SWOT analysis is not a one-man job. The more viewpoints are expressed, the better the results are going to be.

Dialogue: Dialogue is an essential part of a good analysis, so spare no time and effort allowing for it.

Balance: If the matrix is suspiciously one-sided, it’s worth going with at least 5 elements per category.

Decision making

The matrix you get by conducting the analysis is still not enough for success. You need to assess the results as well. The ways to do that are plenty with their usefulness, depending on the original question that made the whole analysis necessary.

If it was an open question (like what kind of product should we develop), there’s a wider variety of possible questions based on the matrix. For example:

  • What opportunities are made easier to use by our current strengths? Identifying these could get us ahead of competitors.
  • How can we avoid threats? How can we avoid having to face our weaknesses? Questions like these can point towards strategic change, even perhaps entering a new market.

If the analysis is conducted after the decision, questions should focus on implementation.

  • What particular strengths are important to reach a given objective?
  • Which of our weaknesses constitute the biggest threats and what are we doing against them?
  • Which opportunities must be used at all costs to reach our goal?

All questions should be examined in the context of the whole matrix, even though they might seem to focus on particular areas. A SWOT analysis is not just another meeting. It always shows the organization’s knowledge at the moment it’s being conducted. Given this, it’s worth repeating it regularly, especially in an environment that constantly keeps changing.

SWOT analysis in an Agile environment

Even though it is a tool used primarily by traditional management, Agile can benefit from it as well. SWOT analysis in Agile can be used when transitioning to Agile, at the beginning of product development, before new releases, or during product or team level retrospective meetings.

Additionally, SWOT analysis in Agile can be of great use when we as Scrum Masters or product Owners feel like our team is out of balance either because of being overly confident or due to the lack of motivation. Emphasizing internal strengths and weaknesses can help re-balance the team.