How to Simplify Your Workflow With Visual Task Management

Success for agile software teams revolves around collaboration, flexibility, and efficiency. Whether you're a coach or Release Train Engineer supporting multiple teams, or a scrum master or engineer aiming for improvement within your team, honing your dependency management skills will boost efficiency and productivity.

While dependencies often seem like hurdles, here's an insight: they can be a powerful strategic tool to enhance your agile team's performance. In this post, we'll explore how you can leverage dependencies to guide your team towards greater efficiency and success.

Agile Team Autonomy

At the heart of agile is the concept of autonomy and self-management. It's all about empowering teams to own the end-to-end delivery of their work with minimal dependencies. This means optimizing their workflow rather than relying on other teams to deliver value to users. When teams need to depend on others, the flow of work becomes less predictable.

In larger, more complex companies, dependencies are often unavoidable due to the sheer size and intricacy of systems. The real challenge is transforming these dependencies into opportunities for improvement rather than roadblocks. By improving the visibility of these dependencies, teams can better understand them, prioritize and sequence work effectively and manage delivery planning and execution more efficiently.

More than one-third of agile teams report that team silos and the delays that result are a problem

17th State of Agile Report, Digital.AI

Dependency visualization

Improving the visibility of dependencies starts with open communication and transparency. When team members are comfortable sharing their tasks and challenges, you create a culture of trust and collaboration. This transparency is critical for identifying dependencies early and managing them effectively.

Software that allows teams to map out dependencies clearly can be a great tool for improving the visibility of work, making it easier to track their status and plan accordingly. Regularly updating and reviewing the dependencies you've mapped keeps everyone on the same page and helps you anticipate potential bottlenecks before they occur.

Easy Agile TeamRhythm is a user-friendly app that integrates seamlessly with Jira to support team planning, which includes visualizing dependencies. You can display dependencies by type and risk, and see dependencies both within your team and with other teams.

Dependency Patterns

Once you're able to see dependencies clearly, you might recognize patterns forming. These dependency patterns can show where a team is relying too heavily or too dependent on another team to deliver work.

Consistent bottlenecks highlight opportunities for improvement, like a change in team composition. When you notice these patterns, it's essential to reassess and implement strategies to become more self-reliant, ensuring a smoother flow of work and improved delivery timelines.

Prioritizing and Sequencing Work

Once dependencies are identified and made visible, you can improve the flow of work by organizing tasks in a sequence that avoids work being delayed by other tasks. Not all tasks carry the same weight or urgency, and understanding the critical path—the sequence of tasks that determines the fastest time to deliver value—can help focus efforts where they are needed most.

Sequencing work thoughtfully ensures that dependent tasks are tackled in the right order, minimizing delays and rework. This strategic approach to task management not only enhances team efficiency but also supports a smoother workflow and avoids delivery being derailed at the last minute.

Better Collaboration

By identifying and visualizing dependencies, you spot bottlenecks early, re-prioritize tasks, and manage delivery plans effectively. More importantly, it empowers your team to take complete ownership of their tasks while constantly improving their workflows.

Remember, every dependency is a piece of a larger puzzle that holds the potential to boost your team's efficiency. By understanding and managing these dependencies proactively, you can ensure smoother workflows, fewer roadblocks, and a highly efficient agile team.

‍

Story points can be a little confusing and are often misunderstood. Story points are an important part of user story mapping, and many agile teams use them when planning their work. But they aren't as simple as adding numbers to tasks or estimating how long a job will take.

Even if you’ve been using story points for a while, you’ll find that different teams and organizations will use them differently.  

So, let’s define story points, discuss why they’re so useful for agile teams, and talk about some of the different ways teams implement them in story mapping and sprint planning.

What are user story points?

Story points are a useful unit of measurement in agile, and an important part of the user story mapping process. You assign a number to each user story to estimate the total effort required to bring a feature or function to life.

When to estimate story points

User stories can be estimated during user story mapping, backlog refinement, or during sprint planning.

Once a user story has been defined, mapped to the backbone, and prioritized, it's time to estimate the story points. It is a good idea to work with your team to do this, as each team member plays a different role in different stories, and knows the work involved in UX, design, development, testing, and launching. Collaborating on story point estimation will also help you spot dependencies early.

It is best to assign story points to each user story before you sequence them into releases or sprints. This allows you to assess the complexity, effort, and uncertainty of each user story in comparison to others on their backlog, and to make informed decisions about the work you decide to commit to each sprint or release.

How to estimate user story points

When estimating story points, you're looking at the total effort involved in making that feature or functionality live so that it can deliver value to the customer. Your team will need to discuss questions like:

• How complex is the work?
• How much work is needed?
• What are the technical abilities of the team?
• What are the risks?
• What parts are we unsure about?
• What do we need in place before we can start or finish?
• What could go wrong?

Tip: If you're having trouble estimating a story or the scope of work is overwhelming, you might need to break your story down into smaller parts to make multiple user stories.

What is a story point worth?

This is where story points can get a little confusing, as story points don’t have a set universal value. You kind of have to figure out what they’re worth to you and your team (yep, real deep and meaningful stuff).

Here’s how it works:

• Each story is assigned a certain number of story points
• Points will mean different things to different teams or organizations
• 1 story point for your team might not equal the same amount of effort involved in 1 story point for another team
• The amount of effort involved in 1 story point should remain stable for your team each sprint and it should remain stable from one story to another
• 2 story points should equal double the effort compared to 1 story point
• 3 story points should equal triple the effort compared to 1 story point… and so on

The number you assign doesn't matter - what matters is the ratio. The story points should help you demonstrate relative effort between each story and each sprint.

Estimating story points for the first time

Because story points are relative, you need to give yourself some baseline estimates for the first time you do story point estimation. This will give you a frame of reference for all future stories.

Start by choosing stories of several different sizes:

• One very small story
• One medium sized story
• One big story

...a bit like t-shirt sizes.

Then assign points to each of these baseline stories. Your smallest story might be 1. If your medium story requires 3 times more effort, then it should be 3. If your big story requires 10 times the effort, it should be 10. These numbers will depend on the type of stories your team normally works on, so your baseline story numbers might look different to these.

The important thing is that you’ll be able to use these baseline stories to estimate all your future stories by comparing the relative amount of effort involved.

Over time, you and your team will find estimating user stories becomes easier as your shared understanding of the work develops. This is where story points become most valuable, helping your team align expectations and plan more effectively.

Make estimation easier

An app for Jira like Easy Agile TeamRhythm makes it easy to see team commitment for each sprint or version, with estimate totals on each swimlane.

Using the Fibonacci sequence for story point estimation

Some teams use the Fibonacci sequence (1, 2, 3, 5, 8, 13, 21, 34, 55, 89, etc.) for their story point estimates, rather than staying linear or allowing teams to use any number (1, 2, 3, 4, 5, 6, 7, etc.).

This has its benefits. For example, if you're looking at a story and trying to estimate whether it's a 5, 8, or 13, it's much quicker and easier to come up with an answer than trying to land on the right number between, say, 4-15. You'll likely reach a consensus much more quickly.

This also means you won't be able to average the team's story points to finalize the estimation. Instead, you'll need to discuss the work and decide on the best estimate from a limited set of options.

But it does limit your options - if you have a story that’s more effort than 34, but less than 55, your estimate might be less accurate.

Using story points to estimate velocity

After some time working together most teams will have a good idea about how much effort is involved in each story point.

Of course, timing isn't exact - there's a bell curve, and story points are designed to be an estimate of effort, not time.

But story points (and knowing their approximate timing) can be useful when it comes to figuring out how much your team can get done each sprint.

You should be able to estimate about as many story points your team can manage during a two-week sprint, or whatever timeframe you’re working to.

For example, if your team can usually get through 3 story points per day, this might add up to 30 story points across a two-week sprint. This is your velocity.

Velocity is useful for user story mapping and sprint planning. When mapping your user stories to sprints or versions, you can check the total story points and make sure it matches up with your velocity so you’re not over- or under-committed.

As you can see there are a few different methods for estimating work. The best advice is to be conservative and not overload the team.

Over time, your estimations should become more accurate.

Using Story Points in Scrum, Kanban, and Extreme Programming

Story points are central to estimation and planning processes in many agile methodologies. Scrum and Extreme Programming (XP) rely heavily on story points to gauge the effort and complexity of user stories.

Scrum teams use story points during sprint planning to decide which tasks to include in the upcoming sprint, encouraging discussion that leads to shared context and understanding of the work.

Extreme Programming on the other hand, uses story points to assess the size of features, enabling teams to prioritize and allocate resources effectively. Teams using Kanban can benefit from story points by using them to set work-in-progress limits and optimize the flow of tasks across the board.

While the specific practices may differ, story points can help encourage team collaboration and a more predictable flow of work.

Sometimes the idea of writing user stories can seem like another "thing" on top of an already busy workload. But for software development teams who are looking to lead their own improvement and deliver software that works for their customers, writing effective user stories is the first step.

If you’re reading this post, it means you want to learn what will work best for the people who use your software, and improve how you approach software development. That's great! Our goal at Easy Agile is to help you do that.

So let’s start with why good user stories are important.

Why write user stories?

You may wonder why you should write user stories rather than writing features or tasks instead.

If this sounds like you, you might not yet have seen the value of writing user stories, and that they serve a very different purpose to writing features or tasks.

It’s easy to get buried in a cycle of feature development that lacks context. The objective becomes more about clearing your way through a large backlog than building solutions that add value for your customers. To build successful software, you need to focus on the needs of the people who will be using it. Your human customers. User stories bring that context and perspective into the development cycle.

What is a user story?

A user story helps agile software development teams to empathize with their customers. Written from the customer (or user) perspective, user stories help the development team understand what they need to build, and why they need to build it.

User stories are simplified, high-level descriptions of a user’s requirements written from that end user’s perspective. A user story is not a contextless feature, written in “dev” speak.

A User Story = the 'what'

A user story describes a piece of functionality from the point of view of the user.

User stories divide features into business processes.

A task = the 'how'

Tasks are the activities that need to be performed to deliver an outcome.

Tasks are individual pieces of work.

How do we write user stories?

You might like to think of a user story as an ‘equation’:

As a [user] + I want [intent] + so that [value]

Let’s break this down further;

As a [user] — this is the WHO. Who are we building this for? Who is the user?

I want [intention] — this is the WHAT. What are we building? What is the intent?

So that [value] — this is the WHY. Why are we building it? What is the value for the customer?

Let’s look at a few simple examples;

As an internet banking customer

I want to see a rolling balance for my everyday accounts

So that I can keep track of my spending after each transaction is applied

OR

As an administrator

I want to be able to create other administrators for certain projects

So that I can delegate tasks more efficiently

Following this equation, teams should make sure that their user stories are ticking all of the following checkboxes:

To write successful user stories:

• Keep them short
• Keep them simple
• Write from the perspective of the user
• Make the value or benefit of the story clear
• Describe one piece of functionality
• Write user stories as a team
• Use acceptance criteria to show an MVP.

Acceptance Criteria

User stories allow agile teams to balance the needs, wants and values of their customers with the activities they need to accomplish to provide that value.

The link pairing these two things together is acceptance criteria.

Acceptance Criteria or ‘conditions of satisfaction’, provide a detailed scope of user requirements. They help the team understand the value of the user story and help the team know when they can consider something to be done.

Acceptance Criteria Goals

Acceptance criteria should:

• clarify what the team should build before they start work
• ensure a common understanding of the problem or needs of the customer
• help team members know when the story is complete
• help verify the story via automated tests.

Let’s look at an example of a completed user story with acceptance criteria:

As a potential conference attendee, I want to be able to register for the conference online, so that registration is simple and paperless.

Acceptance Criteria:

• Conference Attendance Form
• A user cannot submit a form without filling out all of the mandatory fields (First Name, Last Name, Company Name, Email Address, Position Title, Billing Information)
• Information from the form is stored in the registration database
• Protection against spam is working
• Payment can be made via Paypal, Debit, or Credit Card
• An acknowledgment email is sent to the attendee after submitting the form

With this in mind, teams should make sure that their acceptance criteria considers all of the following:

• Negative scenarios of the functionality
• Functional and non-functional use cases
• Performance concerns and guidelines
• What the system or feature intends to do
• End-to-user flow
• The impact of a user story on other features
• UX concerns

Acceptance criteria should NOT include the following:

• Code review was done
• Non-blocker or major issues
• Performance testing performed
• Acceptance and functional testing done
  

Why?

Your acceptance criteria should not include any of the above, because your team should already have a clear understanding of what your Definition of Done (DoD) includes, for instance:

• unit/integrated testing
• ready for acceptance test
• deployed on demo server
• releasable

Writing effective user stories is a valuable practice that will help you and your team deliver software that stays relevant for your customers.

When you embrace user stories as more than just another task on your checklist, but instead view them as an essential tool for creating context and value for your projects, you can stay connected with your ultimate focus - your customer.

Transform your backlog into a meaningful picture of work to gain context for sprint and version planning, backlog refinement, and user story mapping.

Stay focused on your customers

Easy Agile TeamRhythm