Monthly Archives: July 2013
On a large-scale agile project/program with multiple Scrum teams working toward the same overall goal, having user stories sized in a way that makes it easier to re-assign them from one Scrum team to another provides provides a planning and execution advantage when balancing work across teams to optimize delivery dates.
Before adopting a common story points scale, there are a couple of keys to consider in designing the team structures:
- Skill sets should be balanced across teams rather than having teams that are specialized (i.e. don’t have a user interface team, a database team, a services team, etc.). This allows each team to develop entire features rather than individual layers of the application. And just as importantly, it provides flexibility to move user stories from one team’s backlog to another’s, helping to avoid any one team from becoming the critical path.
- Once the teams are formed, the teams are kept together rather than constantly re-assigning people to different teams. The philosophy of “taking the work to the team” helps high-performing teams to continue to produce rather than paying the price associated with forming/storming/norming/etc. every time new team members are added to a team. This can be a very difficult concept for organizations that are accustomed to traditional resource leveling across a department or organization, but it critical to keeping teams operating at peak productivity.
With the team structure in place, features to be developed can then be introduced into each team’s backlog. On a project that is not constrained by a minimum feature set and go-live date (the kind that we read about in text books), the product increment is released when each team completes the features in their backlog and necessary integration/regression testing is complete. When a feature set is needed by a certain date, the project manager will seek to understand if one of the teams is on the critical path and not able to meet the forecasted code complete date. If this is the case, they may need to move some of the features or stories to another team’s backlog. In order to do this, the features and stories need to be sized in a currency that is common across all teams – story points.
On a small, single-team project, each team would be free to define what a story point means to them. On a large-scale project/program, it is important that the story points scale is the same for each team in order to facilitate balancing work across teams. This can be accomplished by identifying stories in the backlog that are representative of each story point size and making those stories known to all of the teams. Team leads then attend other teams’ backlog grooming sessions (especially in the early going) to ensure teams to not deviate from the standard.
- Features and stories belong to the overall project/program, not to an individual team.
Sizing stories using a common story points scale makes it easier to balance work across teams.
Sizing stories using a common story points scale allows for consistency in project reporting such as team-level burndowns or overall project/program
It was six weeks before the big deployment, and tensions were running high across the five feature teams on the project. Just as a team thought they were approaching the finish line, a slew of big and small database refactorings stalled progress. Tables were re-structured. Columns were added or renamed.
One team’s tech lead sent out an email in frustration: “This kind of refactoring of our data model has got to stop. Why are we adding these columns at this point? What is the business requirement that is driving all of these changes? Why did we not anticipate the need for these columns sooner?”
One of the database architects responded: “These changes were not anticipated sooner because this is an agile, not a waterfall, project. “
The tech lead was right to be frustrated some of the refactorings, and the database architect was partially correct that not all detailed requirements are known until close to the end of the project. The database architect was incorrect, however, about agile being the cause of the major changes to the data structures.
- Major structural changes to key entities in the database should not be necessary late in the project – even an agile project. The database architect does not need to know every detailed requirement in order to determine the structure of the data for key business entities given the nature and volume of the data and the technical platform. The data structures for a major business entity should be established before significant development begins using that entity. Some frameworks for scaling agile projects have the concept of an architectural team providing sufficient “architectural runway” for the feature development teams. The data structures are part of this runway.
- Some database refactoring, such as adding new columns, is typically what emerges late in a project when sufficient attention is paid to major structural concerns earlier. These are usually relatively easy for the teams to implement.
- Perform a cross-team assessment of the costs and benefits of refactorings before moving forward with them. Data architects do not always have insight into all of the implications of a database change across all of the layers of an application. If the schedule is tight, things like renaming columns or tables should be deferred. Yes, this is technical debt, but sometimes this is tradeoff that must be accepted in order to meet business goals.
- Build time into the project schedule to do refactorings. Expect that these will happen. Also expect that business stakeholders, especially those that control project budgets, will consider this work unnecessary and wonder why the team couldn’t do all of the database design up front. But of course that’s why we are agile – because we know that as hard as we try, we can never learn all of the requirements up front and we expect some degree of change throughout the course of the project.