Starting the Project: Monday

Previous page
Table of content
Next page

Starting the Project: Monday

You arrive at work well rested and happy. Although the Widget World IT Department is busily setting up your computer for your first day of work, fortunately your office-supply closet contains what you need for today's work:

  • pens

  • 3-x-5 index cards

  • 4-x-6 index cards

Bridget, the Widget World Sales force Automation Tool Manager, sits near you and is ready to work with you on your first day.

Bridget mentions that since Edwina, the Widget World Eastern Regional Sales Manager, is in the office today, she has scheduled a meeting. Harold is a salesperson who happens to be working in the office because of conflicts; he will be available for the next two weeks. Wade, the Widget World Accountant, will be there; additionally, he is available for you 100 percent between 9:30 a.m. and lunchtime, every day if needed.

Off to the meeting, and don't forget your cards.

Getting an Earful

At the beginning of the meeting, after everybody has been introduced, you tell them that you're here to collect stories of what they'd like from the new system and how they'd like to use it.

Using your thousand-year-old technology of pen and paper, document the stories. Put each one on a separate card and insist that Wendy, Wade, and Edwina all partake in the fun. Of course, they may have questions of what is and is not technically possible, who has to sign off on what, and how the workflow goes.

Keep in mind that each story or feature should be broken down so that each is about the same size. This is probably the hardest part as you the developer is needed to keep everything in perspective. Size is about the amount of effort that it would take you to implement the story.

Determining the correct size as a unit of time for each story is not a trivial task, but try to keep the unit of time somewhere from a minimum of half a day, to a maximum of up to a week or two. Again, each story should be roughly the same size. The story size and time estimates will be used later to help you determine the amount of work you're doing and how to better estimate future tasks.

For instance, if one of the features is "Build a rocket ship," break it down into smaller, more manageable chunks such as "The escape pod should be launched within 10 seconds after the escape hatch is closed."

Your nearly all-day session results in the stories shown below. Although documenting the person who suggested it or insisted on it is not mandatory, a method of doing so is displayed here to give you an idea of how the process is often worked out. Starting with physical forms (Figure 22-1) is often a good starting point as it fits with the current workflow and structure.


Figure 22-1

  • Story 1: Edwina: "We track the sales person's contacts using this faxable form" (Figure 22-1) "which is how we determine where to send them next depending on the feedback. Having access to this information in some sort of electronic format would be great."

  • Story 2: Wade: "Collecting all the daily travel expenses and receipts of the salespeople is time consuming and error prone. We'd like to collect them on a weekly basis, subtotaled by day and category."

  • Story 3: Harold: "Sometimes I need to explain a certain expense. For instance, I'll put $30.00 under 'postage' for a special FedEx delivery. I'd like a way to add comments at the bottom of the expense report."

  • Story 4: Wade and Harold: "The expense report should subtotal the items in a manner similar to a spreadsheet."

  • Story 5: Wade: "I'd like to be notified (with a summary) when an expense report is submitted."

  • Story 6: Edwina: "I'd like to be notified (with a summary) when a contact report is submitted."

  • Story 7: Harold: "I'd like each salesperson to receive the same notifications, just so they have the option of double-checking."

  • Story 8: Edwina: "The mailroom needs to be notified when a contact report contains a literature request."

  • Story 9: Edwina and Harold: "Each salesperson needs to have his or her own private login."

  • Story 10: Wade: "I don't authorize the cash advances but still need to track them; add 'Less Cash Advance' to the expense report.''

  • Story 11: Harold: "The cash advances come from multiple sources, so allow the salespeople to control the amount (don't automatically debit it from a special account; just allow it to be entered in the expense report)."

  • Story 12: Wade: "Store the amount of the cash-advance so that I can track the total amount per salesperson."

  • Story 13: Wade: "I'd like to be able to get the data from the expense reports in order to feed it into my special spreadsheets."

At this point you have a plan for implementing the first revision of the software that Widget World needs in order for its sales force to be more productive.

This should round out your first day at work. The client stories that you collected today are the seeds of a plan that is based on the needs of your clients. Of course, you're not going to start writing the software yet, because your plan is not yet complete.

Story Weight Estimation

Now that your story sizes are roughly in the same ballpark in relation to each other, you sit down and try to estimate how much effort it will take to implement each one. This is done by assigning a numerical value to each of your stories. A simple project might have only three values:

  • 1 light

  • 2 medium

  • 3 heavy

Another option is to take a stab at guessing the relative weight of each story implementation by the number of perfect-engineering time units that it would take to implement the story. A perfect-engineering time unit is the number of hours, days, or weeks that you envision a task taking if absolutely nothing goes wrong and your performance is stellar.

For instance, take Story 9: "Each sales person needs to have his or her own private login." Think about it for a moment: Private login means that you shouldn't be dependent on something like Apache's built-in security, but it could run the gambit from PHP Sessions to URL rewriting, to something in between the two. But let's face it: Sessions are not that hard to do correctly if done early, so if you were using the simple point scale it would be rated as a "1 light." If your points are based on "perfect engineering half-days," it would probably still be rated as a "1." However, if your points are based on "perfect engineering weeks'' and the particular story would be complete in a matter of hours, it's an indication that this particular story needs to be more uniform in size with your other stories, which are presumably based on "perfect engineering weeks'' rather than days or half-days.

Walk through a couple more of them:

  • Story 13: "I'd like to be able to get the data from the expense reports in order to feed it into my special spreadsheets."

So, Wade needs access to the expense-report data in a format that is importable by spreadsheet software.

Assuming that the point-system is "perfect engineering half-days," remember that "perfect" here has some liberal but not absolutely perfect presuppositions. For instance, this story was submitted by Wade, the Widget World accountant, and it may very well apply only to his role as an accountant. This means that in addition to using a login screen you'll need to classify the users of the system into Wade/not-Wade, or better yet, accountant/user. Write that information directly on the card.

Spreadsheets can readily import data from files using comma-separated values (CSV files), which technically isn't challenging because it's simply a different view of the dataset.

So, adding user classification system and outputting a dataset as CSV would probably collectively rate at about one perfect engineering day, or in your system of perfect engineering half-days, 2 points.

Take a look at Story 5: "Wade needs to be notified (with a summary) when an expense report is submitted."

This is directly dependent upon the expense report described in story 2: "Collecting all the travel expenses and receipts...." Write that dependency on the card and estimate the story as being "slightly easier than story 2'' and estimate the value after estimating story 2.

Story 6: "Edwina needs to be notified (with a summary) when a contact report is submitted." Note that the functionality is similar to that of Story 5, so write it on each card.

Now go through each one, estimating how long it will take, writing required features on each and noting dependencies between them. Feel free to break stories up if they are too big and conversely consolidate them if they are too small.

Here is the list you now have:

  • Story 1: "Track the sales person's contacts using this faxable form."

  • Basic employee information (1 point)

  • Each distributor/customer can be unique

  • One-to-many relationship between salesperson and customer (1 point)

Putting it all together, making sure that the Web form works and so on, would be another points for a total of 3 points or two perfect-engineering days.

  • Story 2: "Collect the daily travel expenses and receipts of each sales person on a weekly basis, subtotaled by day and category."

    • This is the Travel Expense Report

    • One-to-many relationship between salesperson and customer

    • Wade says it should look sort of like a spreadsheet; this is a nontrivial matter: 4 points

    • Broken down by category: 1 point

    • Getting everything right: 2 points

    7 points total.

  • Story 3: "Comments at the bottom of the expense report."

    • Should probably be rolled into Story 2.

    • Oh no, that makes the relationship more interesting, rather than just being employee to daily expense, we're now charged with employee to daily expense and employee to weekly comments of daily expenses. See Figure 22-2.

    • Keep as separate story but is dependent upon Story 2.

    2 points total

  • Story 4: "The expense report should subtotal the items in a manner similar to a spreadsheet."

    • Although just front-end work, it'll be time-consuming

    4 points

  • Story 5: "Notify accountant (with a summary) when an expense report is submitted."

    • via e-mail

    • e-mail configuration, management, and so on: 1 point

    • actual work: 1 point

    • dependent upon Story 2.

    2 points total

  • Story 6: "Notify sales-manager (with a summary) when a contact report is submitted."

    • each sales-manager has multiple sales people

    • one-to-many relationship: 2 points

    • dependent upon Story 5 but easy: 1 point

    3 points total

  • Story 7: "Notify sales-people with expense-report details."

    • if dependent upon Story 2: 2 points

    • if dependent upon Story 5: 1 point

  • Story 8: "The mailroom needs to be notified when a contact report contains a literature request."

    • Conditional notification: 1 point

    • If dependent upon Story 2 or Story 5, 1 or 2 points

    2 or 3 total points

  • Story 9: "Each sales person needs to have his or her own private login."

    • Authentication: 2 points

    • Authorization: 2 points

    4 points total

  • Story 10: "Add 'Less Cash Advance' to the expense report."

    • Same problem as Story 3 (comments on expense report)

    • Dependent on Story 2

    • Not debited, no account tracking needed

    • Persisted not calculated

    2 points total

  • Story 11: "Allow the salespeople to control the amount of cash advances (don't automatically debit it from a special account; just allow it to be entered in the expense report)."

    • Dependent on Story 10.

    • This story is not really a story; it is a critique of the current system; remove this story and add note: "not debited" on Story 10.

    0 points

  • Story 12: "Store the amount of the cash advance so that I can track the total amount per salesperson."

    • Dependent on Story 10.

    • This story is trivial; add note: persisted

    0 points

  • Story 13: "Export expense report data for spreadsheets."

    • Accountant only: 1 point

    • Work, 2 points

    3 points total


Figure 22-2

You've now broken the stories down and made your first pass at estimation. This step may take several iterations and require going back to ask the clients such questions as:

After you've had the questions answered, however, you still aren't out of the woods. After all, you don't actually know whether the system supports outgoing e-mail, and even if it does, do you know how to do it in PHP?

Refining Your Estimation

Talk with your clients and get the answers to your new questions. It's important that they be available because you don't want these issues to hold up your work. Also, each of your clients (Wendy your project manager, Wade the accountant, Edwina the sales manager, and Harold the salesperson) will be using the system in some respect, so it's really their project and you're the one who makes it go.

Meanwhile, your client questions have been answered:

Q: 

"Can the notifications be done utilizing e-mail?"

Q: 

"Are there indeed three types of users: managers, salespeople, and accountants?"

Q: 

"Can the accountant accept CSV for the expense report export?"

Q: 

"How does the accountant want to specify the export: by employee, by employee and date, or by something different, such as sales manager?"

Answers

A: 

Yes, and any summaries associated with the e-mail should be included as attachments.

A: 

Yes.

A: 

Yes, he does it all the time.

A: 

Just by employees and date.

So now you're left with only the technical questions:

Q: How do you e-mail something using PHP?

Q: What about e-mail attachments?

The Spike

Your clients do not have the technical answers to your technical questions; that's your area. In this case you don't have enough information to to give a complete estimate.

It's time to do some homework, called a spike. Although the work may seem tangential, it is required in order to find out whether your line of thought will pay off or, in this case, answer a technical question.

Set aside some time to determine the if or how questions that invariably show up. These things may take some time, possibly a day or two, but in this case the answer is arrived at in short order. A walk through the PHP API shows us:

   mail("wade@widgetworld.com", "Email Spike Test", "One\nTwo\nThree");

So yes, PHP can send e-mail in an easy fashion, so you need to test it or talk to the admin in order to get it working.

Now, as for e-mail attachments those are not so easy. PHP does not support attaching e-mail as an easy-to-use function, but that's because the MIME e-mail definition is well documented in RFCs such as RFC 822 (message headers), 2045 (MIME), and 2046 (MIME types). So a lot of reading and a little bit of coding result in this tidbit:

   $mime_boundary = "<<<--==+X[".md5(time())."]";    $headers .= "MIME-Version: 1.0\r\n";     $headers .= "Content-Type: multipart/mixed;\r\n";    $headers .= " boundary=\"".$mime_boundary."\"";    $message .= "This is a multi-part message in MIME format.\r\n";    $message .= "\r\n";    $message .= "--".$mime_boundary."\r\n";    $message .= "Content-Type: text/plain; charset=\"iso-8859-1\"\r\n";    $message .= "Content-Transfer-Encoding: 7bit\r\n";    $message .= "\r\n";

The preceding code adheres to the aforementioned RFCs, which define the MIME mail headers (the lines defined in $headers) and the message content before the message is finally put together and passed off to your Message Transfer Agent (MTA). Reading through RFCs can be tortuous work, so be sure to test it on a real mail system, using the same mail clients that your customers use, and get it working without error.

This will have easily burned off at least one point.

Estimation Tips

Now that all your remaining technical questions have been laid to rest, you can confidently go ahead and fill in your story estimates:

Don't fall into the trap of thinking "Oh, 34 points is only 17 perfect engineering days," because the keyword here is "perfect." You'll have meetings to attend, there will be fast and slow days, and you'll have to deal with changes in the plans and many more human and imperfect items.

Plus, this is really only your first estimate; after each story has been completed, you'll write down exactly how much real time it took, and after a week or two your estimates will grow more precise, as will your point-to-time estimates.

But for now, you're happy.

Release Planning

After speaking more with Wendy, Wade, Edwina, and Harold, you realize that the first "release" of this project falls into three distinct segments (you can think of them as buckets). All parties agree that the segments need to be released, roughly in this order:

Customer Contact Report:

Travel Expense Report:

Travel Expense Services:

The decision that they put fourth is that the Customer Contact Report is needed in a more timely manner than the Travel Expense Report. The Customer Contact Report is also a much "simpler" input form with less interaction than the Travel Expense Report, yet the Customer Contact Report would also represent nearly an end-to-end test of the system as a whole.

Each of the buckets in which the stories fall is called an iteration, and in this case each one should take no longer than three weeks to complete. For now, this is the overall plan, and the end of each iteration should produce something that your client can use.

So your first goal is to create the Customer Contact Report complete with logins and notifications for the sales people. After you complete the first iteration, you'll see how well your estimates worked out in several respects:

The end of each iteration is when you take a step back and measure the progress, get feedback from the client, and adjust the plan in accordance with the evolving needs and goals of your client. Don't sweat it too much; this process is designed to be flexible to the needs of both you and your clients.

In this section you learned how to break your problem space up into user-defined stories and how stories can be created and broken out into more stories or consolidated into fewer stories of roughly the same size. Story estimation is an ongoing process, and feedback such as a tangential spike will help to solve technical issues.

It is important to work with your clients to determine what is most important to them and to give them honest feedback regarding the difficulty of each requested feature. This allows you to make better and more timely estimates and allows your clients the flexibility to see the system in action and to make informed decisions regarding the current state of the system.


Previous page
Table of content
Next page
Professional PHP5 (Programmer to Programmer Series)
Professional PHP5 (Programmer to Programmer Series)
ISBN: N/A
EAN: N/A
Year: 2003
Pages: 182
BUY ON AMAZON
Beginners Guide to DarkBASIC Game Programming (Premier Press Game Development)
A+ Fast Pass
A Practitioners Guide to Software Test Design
Google Maps Hacks: Tips & Tools for Geographic Searching and Remixing
Wireless Hacks: Tips & Tools for Building, Extending, and Securing Your Network
The Lean Six Sigma Pocket Toolbook. A Quick Reference Guide to Nearly 100 Tools for Improving Process Quality, Speed, and Complexity
flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net
Privacy policy