Agile Banana

We recently started a sprint with user stories that were dependent on work being done by other scrum teams on a scaled agile project. The Problem The Tech Lead and Product Owner came to me with the initial assessment of the situation. The following nine items of work all needed to be coordinated, otherwise we'd face environment problems that would block progress on other tickets.  Specifically, Team Avocado and Team Bobcat needed to complete items in their sprint, before Teams Candyfloss, Dalmatian, and Elephant could complete items in their sprints. If teams Candyfloss, Dalmatian and Elephant didn't complete their work, then we'd be left with a situation where environments across the project would be broken and potentially inoperable.  Furthermore, an initial assessment by our Tech Lead determined that the items sitting with Avocado were "breaking changes" (represented by sticks of dynamite in the illustration above).  As soon as any one of these pieces of work w...

Up until now, the wireframes for the UI element of our user stories have been produced by our Product Owner, Business Analyst and Tech Lead. The wireframes are typically discussed as part of the story in backlog refinement. Now we have a dedicated UX designer working on the project. But how best to loop them into the scrum teams? My immediate thought was that he needs to be brought in as a full, multidisciplinary member of each scrum Team.  However, I also had reservations about this approach - given that we have multiple scrum teams. Wouldn't this be an inefficient way to do things. To have the UX designer attend the scrum meetings for more than one team seemed inefficient. Must be a better way. In the end, we decided to start by setting the UX designer to work on producing wireframes for particular user stories. When these user stories were going to be discussed by each team, the designer would come along to Backlog Refinement / Sprint Planing, talk through the wireframes, and an...

"We need a burn-up chart so we can see if we're on track." This was a request that came from programme management, and needed a bit of unpeeling.  What are we trying to achieve with the burn-up chart? What is the problem that we're trying to solve? After talking through a few examples of burndown charts, and the reporting features in Jira - we decided that ultimately, the question we were trying to answer was this: "are we on-track to finish the product in time for its scheduled launch date?" So -- what do we need to answer this question?  The first thing that sprang to mind was a list of the must have requirements for the first product release. Without this, we wouldn't know what we were monitoring our progress against. Although we had a list a epics that we knew were needed for the release, these were very (VERY) high level. If they had been estimated, I wasn't aware of it. But then the uncertainty in my mind was how to track against the must haves...

The Scrum Guide is the lightweight introduction on how to get up and running with Scrum teams. It’s written by Ken Schwaber and Jeff Sutherland, the creators of Scrum. The Scrum Guide describes Scrum in a nutshell (p. 3): A Product Owner orders the work for a complex problem into a Product Backlog.  The Scrum Team turns a selection of the work into an Increment of value during a Sprint.  The Scrum Team and its stakeholders inspect the results and adjust for the next Sprint.  Repeat But what does this mean if I want to get started with Scrum? Well, here are some simple steps: Step 1 : Appoint a Scrum Master to help accomplish and coordinate the following steps... Step 2 : Get someone who understands what the outcome of a project needs to be from the perspective of your most important stakeholder – commonly the customer. This person is the Product Owner, who can talk to people about what needs to be done and explain why it has value to the customer and the success of the p...