Agile Development Teams and the Big Picture

Many of the developers I had known over the years loved the idea of creating a super amazing block of code and wanted nothing directly to do with the business. And in the past it was Ok because businesses didn’t need their developers to understand the business to be successful. More likely than not, business and managers told developers what to do and how to do it.

Today the world is changing and to be competitive, business cannot spend time telling the developers what and how to do their work. These days and for the foreseeable future, developers need to step up and take on additional responsibilities understanding what the work is so they can make good decisions on how to do it. Developers need to have that big business picture. And businesses need developers to have that big picture so they can contribute directly to the business, becoming partners with managers and business leaders, to be successful as one team.

If you’re a Scrummaster or Agile Project Manager, you’re probably spending time every day trying to find ways to improve your teams. If the development teams can be made to feel a part of the bigger business picture and can see on a day-to-day basis how they contribute to that big picture, they’ll make the transition from local thinking to system thinking, or sometimes stated as, “Think globally, act locally“.

Below are a few ideas for the Scrummaster and Agile Project Manager to consider around 3 key ceremonies of Scrum where a small change could make a big difference in the development team working in a global environment.

Sprint Planning

I’ve often been to planning sessions where both halves are more technical than is comfortably Scrum. The customer and the business value of the user stories at the top of the product backlog are rarely mentioned. The second half of the planning meeting is meant to be technical but not the first half. The first part of the sprint planning meeting is about user stories which translates to being about business and customers. The goal of the sprint is not about creating amazing technical solutions, the goal is about solving an amazing customer’s problem. The business plan is structured such that when we solve a customer’s problem, we help achieve a business goal. This idea is frequently forgotten and the sprint planning session is an idea time to reinforce why we’re doing the sprint in the first place. The desired outcome of the sprint is real value for the customers and real value for the business. Let’s not lose focus of this.

Scrummasters and Agile Project Managers ensure the development teams know and understand how the sprint outcome affects both customers and business stakeholders. Agile focuses strongly on the customer: Agile Manifesto-“Customer collaboration over contract negotiation” and the first Agile principle, “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software”. But business is not forsaken with the Agile principle, “Business people and developers must work together daily throughout the project”. Every User story is (hopefully) traceable back to the business plan. The business plan or business goal is atop the columns in your User Story map as illustrated here.

The product owner presents both the customers’ and business’ point of view during the first part of sprint planning. The team creates a sprint goal that may encompass the customer goal, the business goal, or a combination of both. Measures: Use a sprint planning checklist of desired activities including why the sprint matters to both customers and business. Track adherence to the checklist.


I would speculate it’s a rare thing if a development team could not be more open, more transparent of their progress through the sprint. Although 15 minutes of each day is devoted to a one day planning meeting, the daily stand-up, the remaining 7 hours and 45 minutes of the day can seem mysterious to stakeholders and customers. “What is the team doing? How can I know they’re progressing?” are questions that come up a lot. Business stakeholders also want to know how the team is improving so they know this sprint is better than the last and the next will be better than the current.

Scrummasters and Agile Project Managers can help the development teams be more open and visible about sprint progress to the stakeholders. During the sprints, it isn’t always clear what features (Epics) have been done, what Epics & user stories are in progress, and which Epics & user stories will be next. Stakeholders cannot ‘see’ progress and results at a glance. By creating and maintaining a User Story map, prominently displayed on the wall, your teams, your managers, your project stakeholders, executive team can quickly assess what’s going on in the project. When I’ve done this, I’ve seen the CEO bringing board members to the wall to enlighten them on the business’s latest big project. Below is a nice graphic from Steve Rogalsky‘s blog post, “How to create a User Story Map”. If you look at the user stories within the release stream, you can see annotation for those stories in progress (WIP) and those competed (Done). When my teams did this, they also used colored dots to indicate the expected sprint.

The User Story map is a one-stop shop for project information. If you’re a large organization using the Scaled Agile framework (SAFe), User Story Mapping can easily be appropriated for Portfolio Kanban, Value Stream Kanban, and Program Kanban. Measures: For measuring the adequacy of visibility, it is likely that you’ll need to speak with stakeholders and managers alike to get their depth of understanding of the project. It would be best to gather this feedback while standing in front of the User Story map. Take special note of what understanding is missing so you and your teams can make any appropriate corrections or additions.

Scrummasters and Agile Project Managers ensure the development team is following highest engineering standards and highlight where these can be enhanced. In my experience, development teams can overlook the positive aspects of the more engaging engineering practices such as test driven development (TDD), pair programming, refactoring, and continuous integration. The main reason for abandoning these is usually time constraints. Development teams are pretty much working in ‘the here and now’ so it’s hard to convince them to do certain practices if short-term results are hard to see. To get teams to use these or other engineering practices, will probably require management support and very good measures to provide fast feedback. Pair programming is probably the hardest practice to implement but one of the easiest to measure using ‘cycle time’. Refactoring is also a hard sell to management and the product manager or product owner. Making code easier to read, faster to update, more efficient for tests, and easier to maintain doesn’t seem to have value if the code already works. Any effort refactoring appears to take away from doing ‘new’ work. Measures: The more immediate measure for refactoring is the reduction of tests, test cases, and the time it takes to run tests. Reducing test time for example should also make builds faster. Following cycle time for equally ‘sized’ stories is a good way to see if an improved engineering practice is having an effect.

Daily Stand-up

Agile and Scrum communities have made it very clear that the daily stand-up is not a status meeting but it usually degenerates into a status meeting over time. Managers demand to know status because, when they and other stakeholders attend these meetings, they don’t often hear anything of value to them. If the meeting included more about outcomes and team commitments it is more likely management will not demand the format be altered. Giving stakeholders the information they want and need can only make understanding and collaboration between development teams and stakeholders better.

Scrummasters and Agile Project Managers ensure the development team understands the value of the daily work being done. An easy way to do this is by having the development team relate their tasks to user story acceptance criteria. Another variation could be how tasks contribute to the goals of the sprint or vision of the project. I suggest using acceptance criteria as this is less abstract and less open to interpretation. Introduce a change to the Daily Stand-up meeting format so the team members talk about the value added. This is done by relating a task to specific acceptance tests/criteria. In other words, what acceptance tests currently failing will pass at the end of the day. This is the team member’s commitment for the day. In my experience, the development team saw this as valuable but more importantly, it made sense to them. A valuable side effect was the reinforcement of the boundaries of the user story. Relating work to the acceptance criteria each day helps keep customer and business value in everyone’s mind throughout the sprint. Don’t make relating a task to an acceptance test be a hard and fast requirement, some work may not directly contribute to passing acceptance tests, but the team should discuss the reasons after the stand-up.  Measures: One measure the team could use is the number of acceptance test cases passing, updated daily.

Scrummasters and Agile Project Managers listen to the team’s discussion during the Daily Stand-up and note when yesterday’s commitment wasn’t met because the task was bigger than expected. Team members make every effort to divide up work on user stories such that each task can be completed within a day (8 hours) or less. Although this isn’t an absolute necessity, it is in the best interest of the team and business to have this level of predictability. Help the development team break down work by viewing work from the core components of: coding, stubs and drivers, unit test, system test, acceptance testing, documentation, scrum of scrums (impact to other teams), and physical delivery. Tasks that unexpectedly take longer than a day can be the subject of team improvement within the sprint or a topic during the retrospective. Measures: One measure the team can use for managing themselves, with a little help from the Scrummaster, is how many tasks took more than a day to complete.


To get the development teams to meet business goals, it’s important that they speak and think in terms of business goals. Companies hire developers for their technical abilities which is important but companies also want these same developers to meet their business goals. The Scrummaster and Agile Project Manager can help develop global thinking within their development teams and the subtle changes above are a way to begin.