As part of the development of the Manifesto for Enterprise Agility, PMI spoke with a range of executive leaders to gather insights on what enterprise agility looks like in practice. Here, Terence Mauri shares how to rethink operating models.
Caregiving is adaptive project management in its rawest form. Uncertainty is not the exception; it is the baseline. This practitioner shares how caregiving helped strengthen her PM skills.
Business acumen isn’t just something that executives or other higher-ups have—it’s a skill that project managers can access and exhibit on a regular basis and within each project, no matter the size of the endeavor or type of industry.
Getting customers to write down requirements is next to impossible. Getting them to review and sign-off 200+ pages of functional details is even more difficult. Fortunately, Extreme Programming (XP) understands and even embraces this reality and recommends an alternative approach to voluminous software requirements specifications: Story Cards.
Story Cards
Story cards are XP artifacts that replace conventional software specs. Instead of documenting hundreds of requirements in one, thick document, the customer (or its representative) writes individual user stories on cards. Each one of these cards describes, in a story form, a single feature of the software.
The advantage of story cards over conventional specs is that not all stories have to be perfect before developers can begin the first iteration of the project. Once the customer has written the most important stories, the development team can start designing and implementing features. While they are busy coding the first set of stories, the customer can write additional stories, or rewrite, adjust and split existing stories in preparation for the next iteration.
What Makes a Good Story
The customer is 100 percent responsible for the stories. Developers may suggest use cases and features. However, the customer has the final word over which stories get approved and their priority. They are accountable for creating the stories, documenting them, and last but not least, making sure that each story card respects the following guidelines:
Describes one (1) single feature
Can be implemented in a reasonable amount of time – usually less than five days
Be prioritized relative to other story cards
Stands on its own (preferably)
Story cards that describe several features or require an implementation effort greater than five days are harder to manage and increase project risk. Consequently, such stories should be split into multiple ones.
Imagine the case where a card describes the following story:
The system should prompt the user to login to the application. When a user tries to access a page without logging in, he/she is redirected to the login page. And when the user's session expires, he/she is redirected to the login page. And when the user is done with the session, he/she should log out of the system by clicking on the 'Quit' button.
This card violates guidelines #1 and #2. First, it describes not one but four related yet different stories. Second, while each feature individually requires little development effort, implementing all four stories at one time might easily keep a developer coding for 10+ days. Splitting this story into four different cards would help the XP team in many ways. For one, it would allow the assignment of stories to different developers, thereby minimizing the duration of the overall task. Furthermore, it would allow the tracker to follow four miniature milestones instead of one, thereby helping him better estimate whether or not the iteration is still on track.
More importantly, breaking the above story into four cards would allow the customer to prioritize each single feature individually. Let's assume that after investigating the stories, the developer comes back with the following estimates:
1.The system should prompt the user to login to the application: 1 day.
2.When a user tries to access a page without logging in, he/she is redirected to the login page: 2 days.
3.And when the user's session expires, he/she is redirected to the login page: 7 days.
4.And when the user is done with the session, he/she should log out of the system by clicking on the 'Quit' button: 1 day
Given the above estimates, the customer might decide to schedule stories 1, 2 and 4 for the first iteration, but story 3 for a future release. Managing this schedule would be difficult if all 4 stories were on the same card, but very easy if four separate cards existed.
Scheduling stories, an activity carried out during an XP phase called "The Planning Game," requires at least two pieces of information. First and foremost, the customer must prioritize every feature or card based on its relative importance in relation to other stories. Then, the feature must be passed to a developer who is responsible for determining how much effort is required to implement the story. Once the effort is estimated, the card is returned to the customer who can then determine, based on the priority and effort estimate, whether the story should be implemented in the very next iteration, or a future one.
The "Stands on its own" guideline is not an absolute must but is extremely practical in XP. While the customer has the freedom to schedule stories for a specific iteration, the development team has every right to tackle stories within that iteration in any order. Continuing with the previous example, a developer working on story #2 should not have to wait for story #1 to be complete before implementing his feature. Furthermore, as soon as he's done with story #2, his unit tests should pass regardless of the status of stories #1 and #4.
Stories with dependencies live in limbo. As such, customers should always strive to write stories that can stand on their own. In the rare event that dependencies can't be avoided, the team should be aware of the relationship between stories and manage them carefully.
Everyone Likes a Good (extreme) Story
Conventional software specs are great for capturing functional requirements. However, very few customers are willing to spend the time and effort writing them. Unfortuntately, a project manager can't afford to have his development team wait for the requirements to be reviewed, finalized, approved, and signed off before starting to code. Given the aggressive deadlines that most projects face, the code freeze date would probably be long gone by the time the development team got a final copy of the specs.
Story cards are an excellent alternative to the voluminous requirements documents advocated by other processes. This efficient and practical approach aligns with the realities of project management. They allow customers ample time to think, document and adjust their stories, while providing developers with written requirements in a timely manner.
Luc Richard is professional speaker and author with over 10 years of experience managing the development of software applications. He can be reached via www.betterprojects.com.
ADVERTISEMENTS
I'm a great quitter. I come from a long line of quitters. I was raised to give up.
