Does your organization have a mature process for breaking down software development projects and update requests into manageable tasks?
Or are developers handed tasks with little communication as to what they need to achieve and who is responsible?
Good work item management practices allow teams to structure work in a way that meets stakeholder expectations while prioritizing work that matters.
In this article, we will explore:
- Why work item management helps dev teams succeed.
- What good project work item management systems look like.
- How we assess those systems as part of our application lifecycle management assessment.
The Role of Work Item Management in Successful Development Teams
Mature work management processes are vital for a successful and organized development process. A good system can make sure requests are accounted for, and that confusion and delays are avoided, says Steven Souther, president of Lagility. It “can also help to identify any risks or potential problems associated with the work.”
People and processes are vital to making the system work, he continues. It’s important to identify project sponsors and project managers, as well as the team members responsible for the work.
“Finally, it should also include the development of a project plan,” Souther writes. “The project plan should detail all aspects of the project and should be updated regularly. The project plan should be reviewed by the manager and the project team members and should be approved by the sponsor.”
A mature work item management process means an organization isn’t working in a “zero-information environment,” says Joseph Gefroh, VP of engineering at HealthSherpa.
“An effective intake process importantly makes status and progress visible to the requestor, providing clarity and improving cross-departmental collaboration and trust,” he writes.
“This clarity promotes better synchronization as dependable intake cycles can be planned with in mind, especially important when collaborating with departments that have longer cycles, such as Marketing and Sales for go-to-market initiatives.”
4 Ways to Assess Work Item Management
Great work item management processes make it much easier for development teams to build applications and meet stakeholder expectations.
That’s why it is one of the most important aspects of our application lifecycle management assessment. As part of the process, we analyze the people, processes and tools involved in the following ways.
Stakeholder and Routine Management
Clear communication with stakeholders is essential throughout the work intake process. Businesses need a structured routine of accepting requests and regular communication with key stakeholders to ensure they are staying the course.
In doing so, development teams ensure they are constantly aware of what is being asked of them, and stakeholders can understand how feasible their requests are and how long they will take.
Work Intake Process Definition
Development teams must have a clearly defined process that covers how project requests are accepted, broken down and then prioritized, says Bill Clerici, CEO and partner at Kingsmen Software.
Most companies have several ways to submit work requests, says project and portfolio management consultant Tim Washington, and this can become a problem. “Without a common work intake process, it can be nearly impossible to track all of the work being done because there is no ‘single source of truth,’” he writes.
Worse still, development teams may be completing “shadow work” — work that isn’t accounted for yet consumes valuable resources.
Work Breakdown Management
Once projects have been accepted, development teams need a method of breaking down work into manageable tasks.
Settling on the right task size can be a tricky balance. You don’t want to break work down into something too granular, but the task does need to be small enough that technology teams can come in, understand what you’re looking for and see whether they’ve done things like that before.
A repeatable process is key, says Kingsmen Software CIO and partner Denise Beachley. “Businesses should follow the same steps every time they get new work,” she says. “They should break down that work into the same kind of structure and even name things the same way. Unfortunately, a good portion of organizations that we go into rarely have these systems in place.”
Relatedly, teams need a way to break down work in a way that makes sense, says Bill Cereci. That means breaking work down in a logical manner.
An example: Imagine you ask for a new business capability, then first break that capability down into a set of business features. Going down a level further, what are the functions that enable that feature? Once you’ve got to that point, development teams should be able to understand the effort required to develop those functions. And, before you know it, you’ve got a tree diagram or work breakdown structure that visualizes the extent of the work.
Creating a work breakdown structure is helpful for several reasons, Christine Organ and Cassie Bottorff at Forbes write:
- It breaks down projects in a way that makes them less overwhelming and more achievable.
- It provides clarity for every team involved in a project, allowing individual teams to focus on their specific tasks while also being able to see how their works fit into the wider project.
- It measures project completion and provides milestones that make it easier to allocate resources.
Sizing and Prioritization Methodology
Finally, teams need a process for accurately sizing projects and prioritizing development. Ideally, development teams should have a methodology that lets them report back to stakeholders to show what they asked for and how the project can be broken down.
In doing so, development teams make sure they are on the same page as stakeholders, and that all of the requirements have been scheduled and sized. Moving forward, development teams and stakeholders can work together to prioritize development tasks, knowing in advance how long each task will take.
It is essential that as many people as possible are involved when sizing and prioritizing tasks, says Dan Radigan, product owner at Atlassian. “Each team member brings a different perspective on the product and the work required to deliver a user story,” he writes.
“For example, if product management wants to do something that seems simple, like support a new web browser, development and QA need to weigh in because their experience has taught them what dragons may be lurking beneath the surface.”
He also recommends teams use story points rather than time periods when estimating work. Rather than signifying the time required to complete a task, story points symbolize the amount of effort it will require to build and implement a feature.
Story points win out over time-related measurements for several reasons, Radigan says:
- They take account of non-project work like meetings and emails.
- They have less emotional attachment than dates.
- They can be assigned quickly and without much debate once the effort of each point has been agreed.
- They keep developers focused on shipping work rather than time spent developing.
Discover Work Item Management Processes With Kingsmen Software
Forming a part of our application lifecycle management assessment, our analysis of work item management processes shows how well dev teams set and meet expectations around accepting and prioritizing work.
Teams are scored in each of the areas above, with the results displayed in a heatmap so investors know which areas need improvement.
Find out more about our application lifecycle management assessment and our wider technical due diligence report by speaking to one of our experts.
Images by: Patrick Perkins, Redd F, Christina @ wocintechchat.com