Many readers of Social, Agile, and Transformation know that I’ve recently started a new position as Global CIO of Greenwich Associates. When I came in, I committed to the team that we would rapidly adopt Agile Development and Agile Planning practices in order for us to fulfill our goals. Today, less than one hundred days into this position, we have Scrum running in three programs and Kanban running in a fourth – a great start.

Agile purists would recognize that we are still in the early days of adopting the process, but we are showing measurable results on our goals as we build up the practice. How? By keeping things simple and adapting practices as needed.

Answers to Common Agile Questions

Below are some of the questions I have received from new agile teams across several organizations where I have started the practice. The answers I provide below are tailored to new teams working on the process.

1. 1. How can we write “good” Stories? – Focus on writing Titles that convey the deliverable and gaining a shared understanding of the requirements rather than the particulars of how the story is written. See my recent post, How to Write Meaningful Agile User Stories for more suggestions.

1. 1. What should we do with Stories at the end of a sprint if they aren’t done? In the early sprints, I prefer teams over-commit because it leads to a better understanding of what it means to commit, how to question the intent of stories, and how to begin measuring velocity. If the story isn’t done, rewrite the story to better represent what was Done and write a new story (or stories) on what needs additional work.

1. 1. How should we show dependencies between stories? – Avoid doing this in the early days. It’s a feature sometimes asked by people who are used to working in MS Project and still believe they can project all the tasks and dependencies on a project. Instead, I reinforce agile principles and ask teams to project their backlog and focus on having user stories fully defined and committed for the next sprint.

1. 1. How can we demo a story that does not have a user interface? Purists might argue that a story that doesn’t have a customer-facing deliverable is a poorly written story, but for new teams and ones working on new technology platforms, this may be difficult. Ask the team to demo a test case, a data diagram, or something that illustrates the quality of the deliverable.

1. 1. Should we capture requirements gathering as a story? There’s nothing fundamentally wrong capturing these as tasks especially if multiple stakeholders are needed to work on the requirements.

1. 1. How do we represent non-technical tasks? Agile is not just for technology work and the practice produces better results if all aspects of the Product are represented as User Stories or tasks. So yes, capture the data work, training, marketing, and other business activities as a Task or other issue type in your backlog and sprints.

1. When can we see a schedule? – Agile teams need to run first, worry about plans and schedules second. Get the backlog going and commitment running first and focus teams to prioritize on value and risk. Once teams get through sprints and resolve most of the open questions, their ability and willingness to project the full backlog emerges. It’s only when there are credible backlogs and understanding of velocity that more realistic scheduling becomes possible.

Further Reading as Teams Advance

Here are some of my more popular posts on advanced agile development practices. Many teams are concerned about consistency when advancing from multiple agile teams to an agile organization. I have several posts on estimation and this one on feature estimation is a good start. Many teams are also interested in increasing their velocity or better integrating agile with software architecture practices. Here’s one if you are working with offshore or distributed teams and one if you are still working on getting the CIO or an executive sponsor for the agile program.

It takes time. One sprint at a time!