backlog prioritization

6 Main Reasons Why You Must Identify Backlog Item Dependencies

Posted on by

6-main-reasons-must-identify-backlog-item-dependenciesWhen creating and grooming a backlog in an agile project, it may come as no surprise that there is a constant need to manage it throughout the product’s lifetime. Common expectations from those who come from the waterfall mindset, is that you would just set up a backlog and the rest should take care of itself. But as you will eventually find out, you must identify backlog item dependencies.

The reality is that the moment you create the first backlog item, metaphorically it becomes a living organism. Many may think that the most challenging part of the backlog item, would be to fully define and estimate it. It certainly is one the earliest challenges in the backlog definition phase. However, it is important to consider, that with each additional backlog item that is created, there is an increasing need to consider inter-dependencies between all items. Not a daunting task if your list is limited to 10 or 20 items, but what about a typical project where there are over 50, 100, or more items.

Without putting the carriage before the horse, it is important to consider those backlog item dependencies initially with a backlog roadmap. Then it is also necessary to make it an absolutely regular activity to take on when backlog grooming. Below we identify the many reasons why backlog item dependencies need to be identified and linked to their co-dependent items.

1. Reduced Overall Project Risk

One of the main reasons why projects fail, is that there is no planning or overview of a roadmap before starting. Certainly, an agile project will prevent most of that with the regular sprint iterations and planning that happens before each is ready to start. However, what we are referring to here is more about consideration of what needs to be built, the moving parts, before all pieces of software or product can be put together. As an example, you can work on the roof of a house long before the house is actually built, but you eventually need to know that you need to build the foundation and structure before you will get to the roof installation. Further to that, you would need to identify the structural specifications (dependencies) to know that the roof will fit when the time comes to finalizing the house.

2. Value-added Efficiencies in Process Workflow

When your project is in mid flight, the last thing you want to get stuck with is realizing you just randomly selected some backlog items that don’t make sense to be in the current sprint. In the worst of cases, you would likely just leave it out as part of the grooming process. But on the other end, you would want to avoid idle time mid-sprint realizing that there were a lot of items that could’ve, should’ve, or shouldn’t have been there to begin with.

3. Facilitation of Priorities

As you identify dependencies early on in the project, the priority of all backlog items naturally present themselves. Like a seemless puzzle being put together from top to bottom, relating backlog items to see if there are or aren’t dependencies is tedious at first, but it becomes easier to balance as the software or product is being built.

4. Early Elimination of Blockers and Time Wasted

On a day-to-day process, through scrums and standups, a well groomed backlog allows for all team members to avoid getting stuck on blockers. Some blockers are inevitable based on the circumstances of the development process. But there can easily be blockers present on some aspect that could have easily been prevented, i.e. environment availability for a developer who would like to commit their code. Some blockers can have workarounds, but inevitably, the longer it is blocked, the more likely there will be time waste later on.

5. Proactive Conflict Resolution within Teams

When the teams gets to see the benefits of dependency identification, they will go on to assure there is regular backlog grooming almost intuitively. Each member’s best interests will gear toward pro-activity so that there is the least amount of conflict. Further to this, the team will be better prepared to resolve conflict should there be at any point. This is mainly a result of “lessened” levels of conflict. 

6. Increased Morale within Teams

As a direct result of lessened conflict, there will be heightened synergy among teams. They will have a higher tendency to gel together and get along. Effectively, this will prevent turnover and burnout with members of the team. Low turnover means that the team stays intact over long periods of time, and they benefit from not only being at the performing stage of team synergy, but also from the experience of working together for long periods of time. This benefit is irreplaceable and highly valuable.

Keeping an up-to-date backlog certainly has it’s benefits, but as we can see, keeping specifications up to date is not necessarily all about updating scope or tasks, but also continuously identifying how they are all tied together.

[Image courtesy of tigger11th at FreeDigitalPhotos.net]

 

Agile Culture: Stop Wasting Time On What Can’t Be Resolved

Posted on by

When attempting to make great accomplishments, we tend to look at issues in the workplace, or in everyday life as opportunities to be resolved. This may distract from solutions that are very obvious and perhaps more urgent or easy to resolve. You may have heard of the expression “low hanging fruit.” Typically you would hear this when tackling a new opportunity, or when there’s a clear advantage to achieving a milestone or accomplishment.

Where is Your Company Placing Importance in Their Culture?

Keeping your sights on what the top priorities are, will likely keep things lean and mean. But outside the obvious, we are also referring to what is not obvious. Circular discussions in meetings, persistent and unattainable targets that never get met, can definitely be a drain on time, resources and motivation. Some companies tend to place importance on resolving issues that can’t be resolved as the next step to a break-through. This could be fine if there’s nothing else to do, but as we may all realize, time and resources are usually restricted. In a few words, why concentrate on what you can’t do, when you can concentrate on what you can do? So much time gets wasted on the “can’t do” mentality, when it’s just a matter of approach that needs a switch or refinement. Yes, this may seem a little philosophical at the moment, but being agile does really place importance on what is being done and how to adapt new ideas and processes to what was previously done.

When a team gets stuck in anti-patterns like analysis paralysis, a stagnant state that is usually caused by concentrating on what can’t be done at the moment, is a direct result to over-analyzing beyond the knowledge, developments, or tools available today. So if your team collectively doesn’t have the knowledge or tools, the low hanging fruit may just be to concentrate on obtaining the very knowledge or tools that will get you to the next step.

Getting out of Anti-Pattern cycles

A common cause of what may create a stagnant environment is the thought that all members of a team have all the knowledge needed to resolve an issue. But again, this is more of a pretentious approach whereby everyone avoids the realization that some learning is required. The problem is, nobody tends to want to step up and be the one to say that they don’t know. This kind of attitude is usually shunned upon and seen as weakness in many companies. But what does it really mean to be “weak?” Is it admitting that you need to do some learning and getting right to learning? Or admitting that you know it all and that you can waste everyone’s time pretending that it can be done?

Learning is Not a Weakness

Ultimately, what we can observe in the situation above, is that company culture can affect the decisions and approaches that employees will take. It’s not about always taking the safe route, but allowing for mistakes to be made, and also not to perceive those who admit to needing more to learn as being the weak ones in the room. In fact, this is probably the reverse, those that need the most learning and admit to it, will actually be your strongest employees. These are your true pioneers, as they have the approach needed to admit failure in times when it’s necessary to take a bold new step to a break-through process, or discovery. The company culture will guide that behavior, so it is best to re-evaluate and adjust accordingly.

[Image courtesy of stockimages at FreeDigitalPhotos.net]

5 Guidelines From Agile Modeling for Agile Best Practices

Posted on by

agile-modeling-guide-agile-best-practicesThroughout the life of project there are many potential pitfalls to implementing and practicing agile. As the agile principles and values are put into practice it’s important to take steps that keep the path of agile best practices for which you are looking to benefit from. The use of Agile Modeling is an excellent way to integrate agile principles and values that can complement almost any other agile methodology (i.e. Scrum, XP, etc.).

Agile Modeling components don’t all need to be implemented to make your project agile, however the more you can put in place with thought and importance in each project situation, can provide solid benefits over time. Most importantly, they provide a good framework to building an agile mindset, and integrate seamlessly in an ongoing agile project. The following is a short list of some components:

1 – Active Stakeholder Participation

As with any agile project, the best way to guarantee success is to make sure your stakeholders are involved at all times. The Product Owner usually is the voice of the stakeholders, and we would all hope that it is always that one person that could speak for many. The importance of “Active” is the key to success. There can be times where stakeholders come out from hiding and suddenly become a decisive voice (make or break) in the success of a project. Late stakeholders that become active at the end of a project open big risks as it is the most costly point at which to make changes to accommodate their expectations.

2 – Document Continuously and/or Document Late

Notice here that we mentioned “and/or,” as an approach to documenting your deliverables. It likely will depend on the type of solution and dependencies of functionalities between features as deliverables. That is to say, it’s always best to document continuously so that you don’t have to wait until the last-minute to remember which features were implemented in your solution. As expected in an agile iterative nature, you are looking to deliver a potentially shippable solution at the end of each sprint. This would require regular documentation revisions if the features were to change and evolve drastically over the course of numerous sprints.

Admittedly it sounds contradictory, but this is where it would be best to document late, since it would be less wasteful if you were to document your deliverable once all features were integrated as much as possible. Particular attention needs to be placed on the nature of the product and development. As in the case of software development, releases occur frequently, some major and some minor. Some consideration as to what will be major and minor can allow for less waste when it comes to documenting.

3 – Iteration Modeling

As the initial part of any iteration, we expect take some time for planning. Usually that time will vary from a half day to an entire day depending on the duration of your iteration/sprint. Iteration Modeling outlines the features and design of what is expected to be delivered by the end of the sprint. Some features may end up being developed in sub-parts over a number of sprints, as well as entire parts. The importance here, is to outline how modular some features may be to the rest of them. With that in place, it becomes much easier to prioritize a sprint backlog, which brings us to the next point.

4 – Prioritized Requirements

There are many factors that go into prioritizing requirements, but the one starting point to attaining this is to actually have a backlog (or list of work items) in the first place. In most cases this Sprint Backlog will come from a much larger list called the Product Backlog. As many practitioners soon find out, prioritizing is a key activity that requires identification of numerous factors such as: ROI, risks, stakeholder needs, functional dependencies, available resources, etc.

5 – Single Source Information

If there is one thing that can cause duplication is a highly bureaucratic and disorganized framework from which an organization is set up. Although seemingly simple, having one single source of information is a major challenge for an organization. Many will point to 1 wiki page as a source of information, whereas other departments try to set their own identities and create their own versions of information that gives them a sense of purpose. From an agile project approach, it is extremely important that all parties learn to use one source of information so that it is updated in 1 location to reduce redundancy and waste.

Many companies today, still strive to revise documents of the same content, but in different locations every time there’s update. Beyond just the internal operations, the complexity of multiple sources increases when working on a project where the client looks to use their own sources of project information in conjunction with that of the vendor’s information. In this scenario, duplication is not efficient and is highly wasteful throughout all organizations, as everyone struggles to find out which is the latest version of the code, documentation, template, etc.

More Agile Modeling Guidelines

From an Agile Modeling perspective there are many more components that make up the framework of agile best practices. The important factor to consider is that it will not be an overnight implementation, nor will it be an overnight success. It takes a considerable amount of time and resources to make an agile system work, but unfortunately, not many want to invest, and expect instant gratification. As history will show, even the concept of instant plug-and-play came with a series of bugs and fixes.

[Image courtesy of Stuart Miles at FreeDigitalPhotos.net]

 

How to Manage Epics as an Agile Tool in Planning

Posted on by

how-to-manage-epics-as-an-agile-tool-in-planningAs part of a large project, you may have a complex product to develop. Whether for intangible (software, games) or tangible (hardware, electronics), there is a need to structure your backlog by level of complexity and size. Although we typically do not go so far as creating Epics in all agile instances, they can prove to be a handy agile tool if created and used in an organized fashion.

The idea behind Epics are to create a sense of commonality between multiple user stories. It is important at this stage to be sure your agile team members are not using the terms for Epics interchangeably with other terms that could drive confusion in day-to-day communication. But along with this defined approach, all team roles (product owners, business analysts, scrum masters, developers, etc) should think of Epics structures and how they will be used going forward. Here we look at Epic examples in hierarchies for Features, Themes or Requirements.

Features in Epic Hierarchies

One way to look at an Epic is to identify it as the high-level feature. As an example we are referring to the physical features of a landing page on a website. It would have a header, footer, content, images, media, etc. With that you can further breakdown the characteristics with user stories, and then tasks to look like the following:

Epic(Feature) —> User Story —> Task(s)
Example: Header —> As user, I would be able to use a search bar to search the site content… —> Investigate Search Bar functionality

Themes in Epic Hierarchies

Epic —> Theme —> User Story —> Task(s)
Example: Landing Page —> Page Structure —-> As a user, I would see 3 columns… —> Create left column, Create right column, Create center column

Requirements in Epic Hierarchies

If you were developing a series of websites for instance, you would need to repeat a set of requirements for each website. In this case you would likely re-use the requirements as you start each website, and then vary those features. The following example would facilitate re-use of the requirements from one website to the next.

Epic(Requirement) —> Feature —> User Story —> Task(s)
Example: Website Landing Page —> Website Page Navigation —> As a user, I will be able to navigate to all site pages from the landing page… —> Create Navigation Bar

There is no definite way to use Epics, these are simply examples. The variations can be infinite and can vary from team to team, project to project, or product to product. But as we know that Epics are typically large user stories, and represent a level above the user story. One thing that needs to remain stable is that the agile team must agree to structure that makes sense for them.

Using Epics to Stay Organized

Using Epics as an agile tool to organize the stories, can enable easier overview of the different product components (features/requirements/themes). As the sprint backlog can list tasks to be developed by multiple agile working teams on different features at the same time, the overview of each Epic can help the Product Owner prioritize stories and interlinking dependencies with each other.

Another useful setup that helps in the structuring of swimlanes for your Sprint/Kankan boards is to have them created according to your Epics. This makes the horizontal divisions clear on the common groupings. It also adds another dimension to manage on your board, but it certainly would be helpful in larger sized projects.

The most important part in creating structures, is to keep it simple. If there is too much team discussion and confusion where everyone is lost in managing the structure, it means that it’s not simple or clear enough. Of course, if all else fails, keep in mind that Epics are not essential. If your team doesn’t see a need for them to exist in your agile product management scheme, just leave them out, as they might not be required due to your project not being as large or complex as originally thought.

[Image courtesy of Danilo Rizzuti at FreeDigitalPhotos.net]

How to Prioritize Backlogs with Agile Teams

Posted on by

When we look at a long list of tasks to complete, we sometimes lose focus on deciding which ones really matter with regard to any specific criteria that would give us the intended outcome. The simple answer is to say that everything on the list is urgent and important, but it isn’t always true. Sometimes level of importance changes with time and it is for that reason (or at least one them), that we have separate backlogs for each sprint in an Agile project. There’s a list of tools that we can use in Agile that would allow us to sort it out, however we need to change our mindset first before we go there.

How do we know what needs to get done first?

When we look at all features we would like to build into our product, we tend to get an indefinite sense of their importance. Common thinking will naturally lead everyone to say that everything in that backlog will need to be done. It may be true, but as we know there are factors to consider before giving all items in a list a high priority. The other issue is that most of us think we know what we want, but then are influenced by factors that are not necessarily our own. From a business stance, we may be acting on behalf of another group of stakeholders, so outside influence might be a consideration to some extent. In certain cases, where there is very little known about a product we are about to develop, an event called an Agile Spike used to elaborate and analyze the feasibility of a suggested product.

Can We Determine the Difference Between Urgent and Important?

prioritize-backlogs-agile-teamsThe first, but often skipped step in prioritizing agile solutions, is to create backlogs with an order based on a fixed set of criteria. Even then, we tend to group items that are urgent and important into the same batch. If we look at the list during agile planning and think in terms of reducing risk, we may be able to get a clearer idea of which items we need to address first. Also keep in mind that risk and value have an inverse relationship, wherein if we reduce risk, we are also increasing value. To think of this in other terms, if we had a usable product that was absolutely risk-free after purchase, we would certainly value it more than it’s risk-prone alternatives.

The second way to look at prioritizing our feature list of items is by looking at potential return on investment (ROI) especially as part of agile release planning. When we get a feature that resolves the majority of risk, but also gives us a monetary return, it should be included as part of a strategic agile product management plan that increases potential for profitability and long-term sustainability. Hence by prioritizing we give ourselves the benefit of continued growth to the business.

Lastly, we can look at what to prioritize from the current market outlook. This would either be in regard to latest or upcoming technologies, purchasing trends, expert insight, demographics, etc. If we anticipate that there are certain events that will take place in the near future, we can give priority to our backlog items.

Recommended Tools:

MoSCoW method, High-Medium-Low, 1-2-3-4-5, Priority-Impact Matrix, Action-Priority Matrix, NPV.

How do we narrow it down?

As always, agile processes are constantly evolving and this is where regular agile courses and agile consulting can add value to your entire organization. There are numerous ways we can prioritize a backlog and structure the thought process. The main point to consider is that we should not base it on a random set of criteria, but rather a more decisive one in which an agile working team can have a fixed set that is used throughout prioritization activities. Your criteria should resonate with overall business goals and targets. The key is to avoid making it overly tedious try to establish the activity as an agile games session (i.e. planning poker), and establish a set of 3 to 4 criteria that everyone agrees on that would facilitate prioritization and make your efforts worthwhile.

[Image courtesy of Stuart Miles at FreeDigitalPhotos.net]