Agile Project Management Tips #3: Use an Insertion Sort for Prioritization

To be successful, Scrum requires a prioritized backlog of stories. Teams focus their efforts during the sprint on the items with the highest priority. Often, explanations of Scrum imply that the Product Owner (PO) already has optimally prioritized the backlog. That sounds like an easy request, until you realize the process required to achieve prioritization. Supposedly, the PO sets the priority, but that assumes a fully informed PO, which may be asking a lot of one person. Each stakeholder involved with the project has his or her own set of priorities, and backroom lobbying for features can cause conflicts. It is better to have a transparent prioritization process.

There are many ways to prioritize the backlog, but some tend to exclude participation more than others do. For example, when using a spreadsheet, database or document to organize the priority, only one person at a time can make modifications, so it is not an inclusive process. In planning meetings, no matter how large the display, the entire backlog cannot be seen at once, so attendees end up seasick watching the screen bounce around while one person sets the priorities. In other cases, when someone has assembled a printed document with the complete backlog, the prioritization process becomes a bubble sort on paper, stepping through the list, comparing items and swapping them if they are in the wrong order; not the most efficient method. In all of these cases, providing a pre-processed list allows some priorities to slip by without any discussion.

A simpler solution is a physical process that involves an insertion sort. In this method, the PO convenes a prioritization meeting and anyone who has a stake in the project can attend. The meeting space must have enough space to display all the story cards on a wall or window. The process steps are:

1. The PO places a random story on the wall, and then pulls another from the backlog.
2. The PO asks whether the current story has higher or lower priority than the one on the wall.
3. People in the room may offer their advice, but the PO has the final authority for placing the story card.
4. If the current story has a higher priority than the one on the wall then the PO places it to the left (meaning higher priority), otherwise it is placed to the right (lower priority). All stories must have a unique priority, so they should all be at the same level horizontally (see Figure 1).
5. Leave space between the cards so it is easier to organize them if a subsequent story is prioritized between two others.
6. One by one, the PO continues with the remaining stories, reading them aloud, getting advice, and then placing them into the correct priority.
7. When all stories have been prioritized, write the initial priority on the front of each story card for tracking purposes because priorities change over time. 

It is also useful to track the priority in a spreadsheet or requirement management system.

Uniquely Prioritized Stories

Using this process, our team has been able to prioritize up to 50 stories in a two-hour meeting. It is not recommended to try for more than this since people get decision fatigue and attention spans decline. Depending on the size of the team and of the stories, it may not be necessary to prioritize beyond the top 50 items. Since the process is an insertion sort, it is easy to split the process into multiple sessions.

The benefits of this approach are:

• Each story has its own moment under the spotlight—there is no a chance for it to be lost. 
• It is a more democratic process, where the stakeholders can lobby the PO on behalf of their preferred stories and the PO becomes more fully informed. 
• The unique prioritization avoids the situation where multiple stories end up with the same priority. It forces people to acknowledge the constraints of time and resources early in the project. It also avoids vague priorities where some stories are “high,” some are “medium” and some might be “medium-high.” 
• The space allows everyone to participate, and the spatial orientation helps people better understand the scope of the project.

There are some potential variations to this process. When two project teams are working in tandem, it is acceptable to create two physical lines. This may expose dependencies. The prioritization process can also help define the minimal viable release points. The PO can move along the horizontal axis to identify the earliest acceptable release point. We maintained the prioritization as we moved the stories to the information radiator (see section 3.5). When a story is added to the backlog, it will have the lowest priority until the next sprint planning meeting when there will be an opportunity to re-prioritize.

<< Previous Tip
Next Tip >>

Agile Project Management Tips #2: Make Your Story Cards Work Overtime

Numerous articles on Scrum discuss story cards. They usually explain how the cards contain a user story, an informal statement about the value of a feature in the system to someone. A common form of the statement is:

As a  , I want  so that .

Most articles explain that the cards are merely an artifact to begin the conversation about the full requirements of the feature. Some teams transcribe the stories into spreadsheets, documents or project management systems.

At this point, some people may toss out the cards, but wait! Even if the story is documented electronically, the physical card has value for the project. Since the principal goal of story cards in Agile development is to raise visibility and focus for each feature, keeping story cards posted in a public place is a good way to do this. Think of the card as an icon for the full feature.

The card can also be a shortcut for the additional details associated with each story. For example, on each card we write a unique tracking ID, the story size, and the initial priority. If the story has a particular champion, the PO writes that person’s name on the back of the card.

An all-too-familiar artifact
This card shows the size, XL,
the original priority, 16th,
and you can see the value was
under debate

As the project progresses, each story card will become a familiar artifact, bringing joy or dread, memories and ideas. The story card becomes memorable token that stands for the full feature. The position of the card can also carry meaning, like a flag. Turn the card sideways to remove it temporarily from the action. Turn it upside down to indicate that the feature is in distress. If conversations about the story become contentious, use the story card as a talking stick, allowing each person to speak their point of view as long as they hold the card.

Even when a story is tracked electronically it is useful to revert to low-tech by printing the summaries on labels and putting them on sticky notes. For multiple, parallel projects use different colored cards for each one.

A word of warning about using story cards: watch out for the nighttime janitor or strong air conditioning. If there is a mysterious gap in the backlog, you might want to look around on the floor. This emphasizes the need to keep an electronic copy of the stories in a spreadsheet or requirement management system.



<< Previous Tip
Next Tip >>

9 Low-Tech Tips for Agile Project Management

“Somewhere today, a project is failing.” These are the first words in chapter one of DeMarco & Lister's cubicle-breaking book Peopleware. They say that the major hurdles encountered in software development projects are not so much technological as they are sociological. For years, people have been developing and redeveloping the same or similar projects, and yet one somewhere today is in trouble. The problem is that high-tech people, enamored with the technology, look to code themselves out of a problem rather than interact with the team. DeMarco points out that because we go about software development in teams and projects and other tightly knit working groups, we are mostly in the human communication business. In 1987, this may have been a cry in the wilderness, but by the time of the Agile Manifesto in 2001, it was commonly accepted. As the manifesto proclaims, the focus should be on “individuals and interactions over processes and tools.”

Peopleware proposes changing physical work spaces and mental attitudes to promote communication, but communication can also be improved by simpler project management processes. Project management can be tough, especially when technology gets in the way of the goal of developing software that provides value to the users. Creating a complex software system becomes even more difficult when processes rely on other complex systems. Project management is easier if you can reduce complexity whenever possible. Considering this, it is better to choose a simpler, low-tech solution when one is available. Additionally, some low-tech practices can lead to higher visibility, more democratic processes, and simpler solutions.

On my team, the path that led to our current project management process was not a quick one. Having explored multiple project management methods over the years, including modified waterfall methods and a couple failed attempts at Agile, we now use Scrum for most of our non-regulatory projects. We found that some of the techniques learned during our initial Scrum training continue to shine through as excellent practices, especially because they are so simple. Other activities, however, were more opaque at the time. It took repetition, over multiple sprints and projects, before we realized the full value of the activity.

In an Ignite talk, Adam Light asserts, “Scrum moves organization from the individual level to the team level.”  For managing projects, this means:

• Helping people take their ideas into a shared work space in a structured and efficient way. 
• Getting the right people working on the right things at the right time. 
• Building on the shared ideas to create better solutions

In short, it means collaboration: moving the project management process from the project leader to the team. The Scrum Master becomes a team member who has the role of facilitating the progress of the project rather than the project leader.

The Scrum Master provides the tools and environment to make the project easier, and allows the team to self-manage. Self-managing, however, is not a goal but a habit, and like any habit it takes time to become innate. The nine tips discussed in the following sections provide a set of good habits that lead to self-managing teams. They all have the common goal of using low-tech methods to make ideas visible and shared, enhancing collaboration.

The process of developing software is essentially one of taking ideas and making them tangible. Since it is usually accomplished with a team of people assigned to create a complex software solution, it is necessary for the team members to communicate their ideas and opinions to others. High-tech teams often navigate toward high-tech solutions to accomplish this goal, but those solutions come at a cost and can complicate the project management process in unexpected ways.

Even Agile projects are complex. Although Scrum reduces some of the complexity, developing modern software solutions is fraught with risks and unforeseen dependencies. Simplifying the project management process frees the team to focus on creating the solution, rather than occupying themselves with administrative tasks. Additionally, involving the team more in the project management process achieves the Agile goals of collaboration, short feedback loops, and user-centric development.

While all of these tips have been used in conjunction with Scrum, they are not limited to an Agile project framework. Many of these tips may not be new to you, but I hope that you see them in a new light. The low-tech goals of collaboration, increased communication, and democratic processes align with the tenets of the Agile Manifesto to promote face-to-face communication, people over process, and collaboration over silos. 

Tip #1: Take a Field Trip
Tip #2: Make Your Story Cards Work Overtime
Tip #3: Use an Insertion Sort for Prioritization
Tip #4: Keep the Sizes Relative
Tip #5: Broadcast with Information Radiators
Tip #6: Draw Out Ideas
Tip #7: Simplify Design with Paper Prototypes
Tip #8: Increase Communication by Pairing
Tip #9: Keep a Project Diary

Agile Project Management Tips #1: Take a Field Trip

At the beginning of every project, we develop a vision document. The goal of this document is to provide a vision of how the product will work once the project is complete. The contents of this document are words and diagrams, pages and pages of writing in an attempt to bring imagination to life. The vision document is supposed to be the inspiration for the project, but often it is a flawed vision only approximating the actual results.

There are two good reasons why a vision document cannot possibly hope to communicate everything. The first is because of the fuzzy front end. A vision document is meant to inspire, but the project could be killed at any point so only a limited amount of work is spent defining the edges of the system. Second, while the vision document may talk about personas, it often does not describe actual system users in the way that a novel might bring a character like Harry Potter to life.

One way to fully realize the environment and characters that will populate your software solution is to take a field trip to sites where the software will be used. Remember the acronym GOOB - Get out of the Building (or -- Get out of the box). Visiting a site brings concrete images to the abstract ideas summarized in the vision document. While it may not be feasible or affordable to bring the entire team on site, even video and phone calls give an enhanced understanding of the environment. The goal is provide a deep impression that will help with development later in the project.

Developer desk <> a dental operatory

The most obvious observations to make are the workflows. The business analyst is best at this process. For the technical staff, the environment may play a factor in developing a solution. For example, dental operatories must be hygienic, so keyboards and mice are wrapped in disposable plastic covers. Since this makes touch screens unfeasible, we had to investigate voice and motion recognition solutions. In other offices, we discovered that staff had such cramped working spaces that they did not have desk space for their paper notes, so they ended up holding them in one hand and typing with the other, which raised a usability issue.

The field trip is a good time to put faces to personas. Previously you may have thought of the receptionist as “Receptionist 1,” but now you know her as Betty, who is extremely good at multi-tasking until it comes to her software. We would not have imagined the reception desk was such a hub of activity until we saw Betty interrupted nearly fifteen times in a fifteen-minute interval. Observing this not only impressed on the programmers and testers the importance of avoiding any software failures, but also provided data for system response times. Betty would be extremely unhappy to take time to call for support if something went wrong with the software.

There are other ways to observe the system: shadowing through screen-sharing sessions, conference calls, setting up role-playing scenarios at work, but none of these bring the situation to life as well as a field trip.

<< Introduction
Next Tip >>

Excellent Animated GIF of Calvin & Hobbes Dancing

Thanks to adamanimates, and of course, Bill Watterson

iOS7 First Thoughts

I updated the iPad at work to iOS7.  Although it's nice, it's not that impressive. 

Simulated parallax view

Here’s a vid of some of the new features.

Some of the things mentioned in the video:

• Parallax background (looks cool, but is it useful?). 
• All the OS apps have new icons
• Some of the new features:
• Control Center - swipe up to get access to airplane mode, etc
• Camera UI is revised - square format, panoramic mode, video is integrated, live filters
• Zoom out from desktop to see the running programs
• Search & URL bars are unified

It seems like Apple has been creating buzz about the lack of skeuomorphism in the new OS.  This first link, from a Guardian article back in June, 2013, almost sounds like something from The Onion.  "Rather than old-school flatness, iOS7 gives you layers of flatness." (Their italics.)

This more current article from Medical Daily goes even further, saying how the Apple flatness is better than Android's flatness. "By contrast, the brain receives just two elements to decode when presented with the experience of the flatter design of many Android devices on the market and under development, testers say. Although this flatter design may at first appear superior, the brain begins to appreciate the richness of experience amid the melding of man and machine."

Update your iTunes if you're gonna update to iOS7

It reminds me of a quote from Spinal Tap, just replace "black" with "flat."

"There's something about this that's so black, it's like how much more black could this be? And the answer is none. None more black." - Nigel Tufnel

Test Plan / Test Diary

There are two parts to testing software.  The first part is planning what to test. The second part is executing the tests and recording the results in a diary.

A) Here's what should go into each item of a test plan:

1. Test Name: Name of the test. Consider this to be similar to a newspaper headline. 
2. Description: High level description, including why this test is useful.
3. Expectation: Expected results from the test.
4. Steps: Steps to perform the test. Include context, if necessary.

B) Each test in a test diary should include references to the first four sections and also

1. Result: Actual results. Describe how it differs from expectations, if necessary.
2. Build version
3. Date
4. Any variables not described in #4 above.

Is this how you create test plans?