Building a Virtual Bullpen with Microsoft SharePoint
My first exposure to a co-located "agile" project team occurred a few years ago when I walked past a large conference room filled with people, computers and large bowls of assorted candies. It was the candy that caught my eye, but I immediately noticed the wall plastered with multicolored index cards, arranged in sections. John, a friend of mine, saw me looking at the wall and stepped over to explain.
"This is our project bullpen, where everyone working on our sprint sits until we're finished," he told me.
"Everyone sits here? Even team members from other cities?" I asked. Most of our projects involved team members from across the United States, if not across the world.
"That's right. They fly in every week."
I was shocked. The index cards on the wall, showing the product and sprint backlog for the project, certainly helped John's team speed up decision-making and improve transparency. But at what cost?
Creating a Digital Bullpen
For the rest of us, a ready solution comes in the form of Microsoft SharePoint. Using the widely deployed portal software, managers can construct a virtual bullpen that provides most of the benefits of collocation without the expense and hassle of flying everyone all over the country. Instead of cards tacked on the wall, you can maintain product and sprint logs in the Web-accessible portal, allowing teams to coordinate activities, communicate status, answer questions and make decisions.
SharePoint custom lists offer a ready means for implementing a virtual bullpen. Custom lists allow you to define simple forms to collect and display information, using views that allow filtering, sorting, grouping and totaling of items in the list. Custom lists can be applied to almost any project managed under a lightweight approach, including scrum or feature-driven development.
The benefits are undeniable. Business partners gain visibility into projects. Teams appreciate the lightweight approach and ease of coordinating efforts. And managers are able to identify and answer questions quickly, while the online bullpen helps keep the project team focused on the objective-delivering software that works.
Work Backlogs
The project management approach centers on two custom lists in SharePoint: the product work backlog and the sprint work backlog. With just these two lists, managers can run both the planning and the day-to-day execution of large, complicated projects, without swamping teams with heavyweight project management methodology.
The effort starts with the work backlog, which is a dynamic list of prioritized work items. This list is always changing -- items can be added, removed, redefined and reprioritized at any time. SharePoint custom lists are a perfect tool for managing the work backlog, because the content can be updated dynamically with widespread visibility. Just as important, SharePoint permissions allow project managers to define lists of people who can view, edit, create and delete items in the work backlog. SharePoint also makes it easy to create views to communicate about the work backlog in effective ways.
Many projects will benefit from two types of work backlogs within SharePoint: the product backlog and the sprint backlog. The product backlog is used for planning and portfolio management -- it's a prioritized list of the business capabilities the team wants to provide at a high level. The product backlog needs to be a dynamic list so business partners can respond to changes quickly and effectively. This list determines the scope of each project sprint.
| PRODUCT BACKLOG CUSTOM LIST |
| FIELD NAME |
TYPE & VALUES |
DESCRIPTION |
| Feature Name |
Single Line of Text |
Descriptive name for the business capability that will be added, i.e. "Capture client income information" |
| Description |
Multiple Lines of Text |
Elaborate on the feature. What does it include? What doesn't it include? |
| Sprint |
Single Line of Text |
The name of the sprint this feature will be built in |
| Planning State |
Choice: Proposed (default), Planning, Active, Completed, Dropped |
What activity is currently happening around this feature? |
| Priority |
Number: 1-10 |
What is the relative importance of this feature to other features in the list? |
| Notes/Comments |
Multiple Lines of Text |
As this feature is discussed and more details emerge, keep a running history of them here |
| Active Status |
Choice: Proposed (default), Planning, Active, Completed, Dropped |
If this feature is currently active, what is its status? |
| Resources (optional) |
Multiple Lines of Text |
What type of resources are required to build this feature? |
| Estimate |
Number |
How many hours will this estimate require to build? |
| Estimate Notes (optional) |
Multiple Lines of Text |
How was this estimate determined? What factors were used? |
| Business Value (optional) |
Multiple Lines of Text |
Sometimes I separate this from the "description" field based on the context of the project |
| Business Sponsor |
Single Line of Text |
Who needs this feature most? |
| Stakeholders (optional) |
Multiple Lines of Text |
I use this field when different features are important to different sets of people |
| SPRINT BACKLOG CUSTOM LIST |
| FIELD NAME |
TYPE & VALUES |
DESCRIPTION |
| Sprint Name |
Single Line of Text |
The name of the sprint this task is part of (should match the values used in the backlog list) |
| Feature Name |
Single Line of Text |
The feature this task is related to. Use "multiple" if it relates to more than one |
| Blocked |
Yes/No (default) |
Check this box when impediments exist that are halting the execution of the task |
| Notes/Comment |
Multiple Lines of Text |
As this task is discussed and more details emerge, keep a running history of them here. I like to use this field to keep track of detailed requirements as they evolve |
| Artifact |
Hyperlink |
Use this field if the outcome of the task is a document kept in SharePoint |
| Date Started |
Date |
When did work begin on this task? |
| Date Completed |
Date |
When did work end on this task? |
| Start Date |
Date |
When should work begin on this task? |
| Due Date |
Date |
When should work end on this task? |
| Assigned to |
Single Line of Text |
Who is going to do this work? |
| Status |
Choice: Not Started (default), In Progress, Completed, Waiting on Someone Else |
What is the current status of this task? |
The sprint backlog is a task list used to run the daily activities of the project. It lists all the activities that need to occur in order to deliver the business capabilities previously identified in the product backlog. It's the backdrop for project scrums, helping the team keep track of what has been done, what must happen next and what obstacles might prevent progress going forward.
Product Backlog Custom List
Creating the product backlog list only takes a couple of minutes. Table 1 describes the minimum fields I use as well as a few additional fields you might also consider.
Once the list is created, the next step is to build out the following views. As your needs evolve, you'll probably add more.
- Sprint View: Group items by sprint name and then by priority.
- Planning View: Group items by planning state and then by priority.
- Active View: Filter out all items where planning state is not "Active" and group by sprint and then by status.
Once the backlog custom list is created, it's time to populate it with the specific features of the project. Avoid being too picky about the details required at first -- one of the reasons the list is dynamic is so it can evolve. Use the list to flesh out the various features the project will provide at a high level, and then add detail to each feature as they approach implementation. I like to use a number and a month as the name of my sprints. It helps me to visualize the progress of the project in my mind by doing it this way.
One tip is to maintain a sprint called "TBD" as the default value. This makes it easy to create new features without touching every single field.
Another helpful idea is to export the work backlog list to Microsoft Excel, where the data can be used to create charts and graphs. For instance, a burn-down chart helps illustrate the type of pace the project team is maintaining in delivering business value. For an excellent discussion of the uses of burn-down charts, visit Alistair Cockburn's Web site at http://alistair.cockburn.us.
The Sprint Backlog Custom List
Like the work backlog list, the sprint task list is easy to build. Start with a regular SharePoint task list and add some fields to it as described in Table 2.
Like the product backlog, you'll need a few views of this list as well, including the following:
- Status View: Filter to include only tasks for your current sprint and then group by status and by feature.
- Blocked View: Filter to include only those tasks where the blocked field equals "Yes."
- Assigned View: Group by assigned to, then by status.
- Overdue Tasks View: Filter to include only those tasks which are not complete and for which the due date has passed.
Once the sprint backlog has been created, use the collective understanding of the project team to develop an initial list of tasks to be completed in the sprint. It's not necessary to assign or schedule these right away -- you're just getting a starting point ready. Managers can add additional items to the list as the project progresses, instead of having to come up with every single task before the start.
Use the same sprint work backlog list for all your sprints. That way, if a feature moves from one sprint to another, you can move all its associated tasks to the new sprint without recreating them. Also, it lets you customize views that cross multiple sprints, such as a view by assignee, which helps track how much work is being done by a single project team member across sprints.
As with the product backlog, you can use Microsoft Excel to create burn-down charts based on the data in your task list. This is a great way to measure the progress of your sprint and estimate when it will be completed.
And it sure beats flying everyone in to stare at a blackboard.