敏捷方法和實現（三）

儘可能的收集需求

爲了本書需要，你將要和一個需要做建設的電子商務網站的假設顧客工作。下面是在你同意去接見顧客時所知道的確切信息。顧客的名字叫Claudia，她經營一個致力於兒童用品的零售商店。她現在緊緊擁有一個簡單的網頁，命名爲店名（Claudia的孩子），還有一些簡單的聯繫信息。沒有更多好的信息供你參考，因爲這不像使用預測方法那樣，你需要適應顧客的需求。

第一天

當你遇見Claudia時，她看上去是一個有活力的三十多歲的人，正是這個人四年前創辦了這家零售商店。這家商店的籌建款是由信用卡、從高薪職位離職後的佣金、親朋好友的借款中組成的。大概整整用了兩年的時間，她纔拿到客觀的收益，但是通過迎合特殊市場（哪些可以花費任何東西去購買兒童玩具和衣物的媽媽們），Claudia獲得了成功。

Claudia十分確信，現在是做擴張的時候了。商店的驚人增長並沒有花費很長的時間，但是現在還沒有足夠的錢來創建另一家實體店。同時她對郵件列表相關的花費也是很不滿意。這正是你和Codeigniter現身的時候。雖然她並不知道如何去架設一個電子商務網站，但是她知道一個交易型的網站是她成功的關鍵——她可以利用一個正確的網站來擴大她的用戶羣體並且能帶來比實體店經營和電話預定更多的收入。

在你一邊聽一邊做記錄，大部分是高級的名詞和動詞。你已經知道一些信息，例如，你需要一些在線商品列表，但是並不確定每件都標明價格、圖片、名稱，還有某種唯一性標示。此外，他們很可能被組織到某種分類列表中，例如玩具或者衣物。但是這就是你現在所知道的一切。你也知道，這必將涉及消費者，但是你不確定她是否想跟蹤每一位消費者的消費情況。

所以現在你可以開始了。現在有的僅僅是解決問題的多個措施。鑑於你在創建此類工程的經驗，你應該知道怎樣去知道當前的討論，這應該是沒問題的，因爲現在討論的正是Claudia所需要的。她在經營和市場方面是專家，而你是代碼方面的專家。通過這點就能建立合作伙伴關係。她最終將成爲商品主，提供給你這個開發者對任務的關鍵描述。

你可以從任何地方開始，真的，但是過去的經驗告訴你不要從詢問底層問題開始。換句話說，試圖去剖析某個產品的每個細節或者分類直接的相互影響只會使Claudia十分困惑。相反，你應該在一張紙上畫一個大矩形，並且表示他爲“主頁”。

你一邊說，一邊在大矩形的頂部附近畫一個水平的小矩形。你解釋說這就是你的網店的logo和主導航欄將要顯示的地方，通過這裏可以跳轉到聯繫我們、關於我們和一些可能的特殊的界面。在大矩形的底部，你畫另外一個小矩形，並且解釋說，這是網站的底部，在這裏將包含版權聲明、隱私策略和其他一些細節。

目前爲止，你已經畫出了類似圖2-1的圖形：

圖2-1

現在，你需要明確什麼將要在中間顯示。你可以建議顯示一些突出的元素或者一些關注點或者可視化的娛樂信息，但是網頁也需要用戶能快速便捷的導航到網站中的任何一點。

是的，Claudia說，顯示突出元素是個好主意，可以是一些能夠保持一個星期或者更長，一些她能夠控制的而不是隨機的。她想要元素的一幅圖片，元素的名稱，一段簡短的說明，還有顯示詳細信息的超鏈接。你建議說在首頁的右邊同時顯示一個“現在購買”的按鈕會更好些，她同意了。Claudia同時認爲在突出元素區域的右側顯示其他元素的隨機列表，可以是每個大分類中的某件產品。列表中的每個元素都會標記一個縮微圖，產品的名稱，顯示詳細信息的超鏈接。同樣，你也要添加一個“現在購買”的按鈕。

現在你所畫的首頁將是圖2-2顯示的樣子：

圖2-2

提到分類，你決定在突出元素的左邊放置一個垂直的長方形，告訴她，“在這裏我們將列出你商店裏的所有分類。讓我們花費些時間討論一下這個地方”。

Claudia點頭告訴你說在她現存的庫存中，她有五至六種主要商品的分類，每個分類還有他們各自的子分類。目前爲止，她的商店中商品分類僅僅有兩個層次，於是你知道你需要創建一個分類的層次樹和一個兩層的導航欄供用戶點擊，如圖2-3所示：

圖2-3

你們兩個共同看一下這張草圖，認爲你的設計是相當棒的。你已經在這上面花費了一個小時，但是你沒有立即停止，而是決定趁熱打鐵來創建其他兩幅草圖：一個是分類的視圖一個是詳細信息的視圖。

Claudia詢問關於“現在夠買”的網頁和購物車的實現。你告訴她這個這個網頁可以在明天畫出來。畢竟，你需要一些時間來消化你從這次會談中知道的每件事情。

你決定在分類視圖中重用那個基礎的矩形。你解釋說這是一個分類的視圖，用來顯示產品的列表，也可以包含其他的分類。例如，如果你有一個衣服的分類，它可能包含一些與襯衫、褲子、裙子、鞋子等相關的子分類。

一個主分類可能和子分類一樣擁有一些自己的產品，但在這點上，Claudia不同意，她想讓零售的能夠顯示出層次感。在商店的庫存清單中，你永遠不會看到某些產品屬於一個像衣服一樣的高級別的分類。你記下來，只有子分類纔能有產品和它們關聯。

我們得到了一個簡單明瞭的視圖，將和主分類關聯的子分類顯示或者顯示每個子分類的相關聯的產品。第一種形式的視圖將按字母順序列出所有的子分類，並且顯示子分類的名稱、簡介和鏈接到這個分類的產品視圖的超鏈接。

當你問及是否允許主分類或者自分類從在線商店中移動或者刪除時，Claudia努力思考了好久，最終同意了。所以現在你知道，你需要跟蹤一種狀態（活動或者未活動），並且只顯示處於活動狀態的分類。

接着，你詢問在每個分類名字和簡介的旁邊是否顯示某種形式的圖片。思考片刻後，Claudia問可不可使用一張和子分類相關聯的隨機的一個產品的圖片。你告訴她，當然可以，但是正好有一個另外的問題出現在你的腦海中，有沒有可能一件產品不止出現一個分類中呢？

對此Claudia甚至沒有考慮多長時間。她搖了一下頭，不會，她說她將商店裏的產品保持得很有秩序，她想在網店中也是這樣。到現在，你畫出了分類的視圖（大分類和子分類），如圖2-4和圖2-5所示：

圖2-4

圖2-5

在你工作的進行中，你留意到其實這兩個草圖其實並沒有多大區別。所有你應該做的就是檢查一下分類的層次，已決定你是要顯示產品呢還是子分類。

在Claudia重溫了一下這些草圖，她提出如果每個產品都提供關聯元素會更好。你把這個作爲你要開始創建的產品詳情網頁草圖的線索。同樣，你使用簡寫的矩形來幫助你創建首頁，但是這次你提供一個空白來顯示產品圖片的大圖、圖片名稱、更長的描述，還有一個“現在購買”的按鈕。

“它並不這麼簡單”，Claudia對你的草圖說，“我們需要提供其他的信息，比如顏色和型號。並且我想在旁邊顯示關聯元素。”

“您所說的關聯元素是什麼意思？”

“是這樣，如果你在查看襯衫時，顯示一些褲子或者鞋子會更好些。”她說。

當你問及這是否是隨機選擇的是，她的回答是否定的，她想像自己的商店裏一樣構建每個網頁。在她的商店中，她都會把全套服裝放在一起，因爲這麼做會促進銷售。

“我們就這麼做了”，你說，感覺應該稍微停下來記一下筆記。“我們將做一個關聯元素的側欄，但是聽上去我們需要找到一個方法，以便在不依靠分類的情況下將產品分組。類似於分組號或者其他的一些東西。所有擁有共同分組號的放在一起。”

她點頭同意你所說的。由於有其他的事情去做，所以她急於暫停一會兒。她看着產品詳情網頁的草圖（在圖2-6中顯示）表達了目前爲止對現在的進程很滿意。

 

圖2-6

“這看上去比我記憶中的高端技術要輕鬆和可視化的多”，她說，“目前爲止你還沒有問任何恐怖的問題，僅僅是一些我知道的十分明確的東西，像我所做的生意一樣。”

你感謝Claudia的接待，並且約定了第二天的見面時間，來討論一下“現在購買”網頁並且在你的指引下佈置一些區域。

消化一下你所瞭解到的東西

祝賀，你已經完成了整個任務。不僅創建了四個草圖（首頁、分類視圖、子分類視圖和產品詳情視圖），但是你同時得到了大量管業分類和產品的信息。

下面是你所瞭解到的關於分類的信息：

❑ 分類是有層次的，但是限制在兩層。

❑  分類可以是激活和未激活的。

❑ 分類擁有名稱、簡短說明和完整說明

❑ 分類的圖片從與他們關聯的產品中取得。

然後是你所瞭解的產品的信息:

❑ 一個產品只能屬於一個分類。

❑ 產品有名稱、大圖片、縮微圖、簡短說明、完整說明和其他可能的數據參數，比如型號和顏色。

❑ 一件產品可以通過組或者套裝和其他的產品相關聯。

❑ 雖然沒有提及，但是可以明確的推斷出產品也可以是處在活動和未活動的狀態。

❑ 雖然沒有說明，但是可以推測一些是必要的，那就是每件產品都要有以十進制表示的價格。

將你所知道的分類的信息轉化爲在MYSQL中建表的查詢語句，你將得到類似於下面的信息：

   1: CREATE TABLE ‘categories’ (

   2:  

   3: ‘id’ INT NOT NULL AUTO_INCREMENT ,

   4:  

   5: ‘name’ VARCHAR( 255 ) NOT NULL ,

   6:  

   7: ‘shortdesc’ VARCHAR( 255 ) NOT NULL ,

   8:  

   9: ‘longdesc’ TEXT NOT NULL ,

  10:  

  11: ‘status’ ENUM( ‘active’, ‘inactive’ ) NOT NULL ,

  12:  

  13: ‘parentid’ INT NOT NULL ,

  14:  

  15: PRIMARY KEY ( ‘id’ )

  16:  

  17: ) TYPE = MYISAM ; 

  18:  

同樣，將你所知道的產品信息轉化MySQL的查詢語句，你將以下面這段內容結束：

   1: CREATE TABLE ‘products’ (

   2:  

   3: ‘id’ INT NOT NULL AUTO_INCREMENT ,

   4:  

   5: ‘name’ VARCHAR( 255 ) NOT NULL ,

   6:  

   7: ‘shortdesc’ VARCHAR( 255 ) NOT NULL ,

   8:  

   9: ‘longdesc’ TEXT NOT NULL ,

  10:  

  11: ‘thumbnail’ VARCHAR( 255 ) NOT NULL ,

  12:  

  13: ‘image’ VARCHAR( 255 ) NOT NULL ,

  14:  

  15: ‘sizes’ ENUM( ‘s’, ‘m’, ‘l’, ‘xl’ ) NOT NULL ,

  16:  

  17: ‘colors’ ENUM( ‘red’, ‘blue’, ‘green’, ‘brown’, ‘white’, ‘black’ ) NOT NULL ,

  18:  

  19: ‘grouping’ VARCHAR( 16 ) NOT NULL ,

  20:  

  21: ‘status’ ENUM( ‘active’, ‘inactive’ ) NOT NULL ,

  22:  

  23: ‘category_id’ INT NOT NULL ,

  24:  

  25: ‘featured’ ENUM (‘true’, ‘false’) NOT NULL,

  26:  

  27: ‘price’ FLOAT( 4, 2 ) NOT NULL,

  28:  

  29: PRIMARY KEY ( ‘id’ )

  30:  

  31: ) TYPE = MYISAM ; 

  32:  

在這裏，對於colors和sizes字段使用enum類型稍微有些不合適，因爲不同類別（一個是鞋子，一個是襯衫，一個是褲子）的型號可以是任何數字並且有許多不同的顏色分類。但是現在來說，給出的這些就夠用了。

當然，畫草圖並且構思MySQL數據表是個好主意，但是在你和Claudia下次見面之前，你需要畫一幅產品的備忘錄草圖。這個備忘錄草圖將會把所有你所希望看到的電子商務網站的特性列舉出來。

記住下面的論述，你（在電子商務網站中）所構建的商品和真實商店中的商品（鞋子、衣服，等）有根本的區別。只要你劃清楚這兩個概念，你將會做的更好。

看過你的筆記和草圖後，你在一些成功經驗（story）的基礎上創建了一個初步的產品備忘錄草圖。一個成功的經驗通常遵循這樣的準則，“做了X，我想做Y，於是我能做Z”。下面是一些你能夠使用在產品備忘錄草圖中的經驗——請記住雖然店主也能夠做這些，但是如果你做出範例的話會使工作進行的更快。

1. 作爲用戶，我能夠瀏覽在首頁中的重點突出產品，並能購買它。

2. 作爲用戶，我能夠瀏覽其他相關聯的產品並能購買他們。

3. 作爲用戶，我能夠瀏覽分類列表並能導航到網站的這部分分類。

4. 作爲用戶，我能夠被導航到商品詳情網頁並能購買商品。

5. 作爲用戶，我能夠在商品詳情網頁中查看相關聯產品，以便於完成配套或者購買搭配商品。

6. 作爲用戶，我能夠在想了解產品的外貌時，可以查看產品的縮微圖和大圖。

這些現在就足夠了。明天，你將會見Claudia讓她來瀏覽你的產品備忘錄草圖。

原文

Gather Your Requirements While You May

For the purposes of this book, you are working with a hypothetical customer who wants to build an

eCommerce site. That’s really all you know when you agree to meet with the customer. The customer ’s

name is Claudia, and she runs a thriving retail store devoted to “all things kids.” She only has a very

basic web presence that gives the name of the store (Claudia’ s Kids ) and some basic contact information.

This is not a lot to go on, which is OK, because, unlike when using predictive methodologies, you want

to adapt to the customer ’s needs.

The First Day

When you meet Claudia, she turns out to be an energetic 30-something who started her retail store 4

years before. The store was funded in part with credit cards, the severance from the high-tech job she

was laid off from, and a loan from various friends and family. It took almost 2 years for her to claw out a

decent profit in the store, but by catering to a specific market (moms who would pay anything to

provide their kids with branded clothes and toys), Claudia has made a success of it.

Claudia’s pretty sure it’s time to expand. It didn’t take long for her phenomenal growth to flatten out,

but there isn’t enough money coming in to expand to a second brick-and-mortar store. Nor does she feel

comfortable with the costs associated with a mail order catalog. This is where you and CodeIgniter come

in. Although she has no idea how to code an eCommerce site, she knows that a transactional site is the

key to her success — she could, with the right site, expand her customer base and bring in lots of revenue

beyond what comes in from walk-ins and the occasional long-time customer who phones in an order.

As you listen, you’re taking notes, mostly about high-level nouns and verbs. You know already, for

example, that you will need some kind of online catalog of products. You don’t know what pieces of

information you will need to track for each product, but you can be sure that each will have a price, a

photo, a name, and some kind of unique identifier. Furthermore, they’ll probably be organized into some

kind of category scheme, such as toys or clothes. But that’s all you know right now. You also know that

there are customers involved, but you don’t know if she wants to track each unique customer.

So now you have a place to start. There are only so many ways to attack the problem. With your previous

experience building these kinds of systems, you know how to guide the discussion, which is fine, because

that’s what Claudia wants. She’s the expert on her business and marketplace, and you’re the expert coder.

From here forward it’s a partnership. She will eventually become the product owner in the process, the

person who provides you, the developer, with the kind of necessary input to delineate tasks.

You can start anywhere, really, but you’ve learned from past experience not to start by asking bottom-up

questions. In other words, trying to dissect every single possible field for a product or how categories

interact would just confuse Claudia. Instead, you draw a big rectangle on a sheet of paper and label it

“home page.”

You tell Claudia that the best way to start is with a prototype mockup. That way the two of you can start

figuring out the major components of each page and from there fill in the look and feel and other details.

As you talk, you draw a smaller horizontal rectangle near the top of the big rectangle. You explain that

this is where the store’s logo and main navigation will go — pages like Contact Us, About Us, and

perhaps special features or deals. At the bottom of the big rectangle, you draw another smaller rectangle,

and explain that this is the site’s footer, which will contain a copyright notice, a link to the privacy

policy, and other minutiae.

So far, what you’ve drawn looks a lot like Figure 2-1.

Figure 2-1

Now, you need to know what goes in the middle. You suggest some kind of featured item or point of

focus or visual interest, but the page also needs to allow users to navigate quickly and easily to any point

in the site.

Yes, Claudia says that a featured item is a good idea, perhaps something that could stay up for a week or

so, something that she could control instead of something random. She wants a photo of the item, the

item’s name, a short description, and a link to some kind of detail page. You suggest that it might be

good to have a “buy now” button as well, right on the home page, and she agrees. Claudia also thinks

that something off to the right of the main feature might be a random list of other items, maybe one

product from each major category. Each item in the list would feature a small thumbnail, a product

name, and a link to a detail page. Again, you fill in a “buy now” link as well.

Your home page drawing now looks like Figure 2-2.

Figure 2-2

Speaking of categories, you decide to put a long vertical rectangle to the left of the main featured item,

telling her, “This is where we’ll list all the categories in your store. Let’s talk about those for a bit.”

Claudia nods and tells you that in her existing inventory, she has five or six major categories of products,

each with their own subcategories. So far, her store only has two levels of categories, so you know that

you will need to build a hierarchical category tree and a two-level navigation depending on what the

user clicks on, as illustrated in Figure 2-3.

 

Figure 2-3

You both look at this mockup and decide that what you have is pretty good. You’ve been at it for about

an hour, but instead of quitting just yet, you decide to push ahead to create two other page mockups: one

for the Category view and one for the Detail view.

 

Claudia asks about the “buy now” page and the actual Shopping Cart. You tell her that this page can be

mocked up tomorrow. After all, you need some time to assimilate everything you’re learning from this

meeting.

You decide to reuse your basic rectangle for your Category view. You explain that this is a generic view

that shows any list of products and/or other categories. For example, if you had a clothing category, it

might have certain subcategories associated with it: shirts, pants, skirts, and shoes.

A main category might even have individual products associated with it as well as subcategories, but at

this point Claudia says, “no”, that she wants to mirror the retail environment to some degree. In the

store’s inventory system, you would never see individual products associated with a high-level category

like clothes. You make a note that only subcategories can have products associated with them.

The result is a fairly simple Category view, featuring all the subcategories associated with a main

category or the products associated with a particular subcategory. The first type of view would list all

subcategories alphabetically, with subcategory name, description, and a link to view products within

that category.

When you ask if it’s possible to have categories or subcategories removed or deleted from the online store,

Claudia thinks long and hard and finally agrees to allow it. So now you know that you need to track some

kind of status (active or inactive, live or in progress) and only show the ones that are active or live.

Next you ask if you should show some kind of image next to each category name and description. After

some thinking, Claudia asks if it’s possible to pull a random image from a product associated with a

subcategory and use that. You tell her that, of course, it’s possible, but something else just occurred to

you: Is it possible for a product to be in more than one category at a time?

Claudia doesn’t even have to think very long about it. She shakes her head, no, and says that she keeps

things very organized in her store and intends to do the same online. So far, your diagrams for the

category views (category and subcategory) look like Figure 2-4 and Figure 2-5.

 

Figure 2-4

 

Figure 2-5

As you work, you take note that there really isn’t that much of a difference between the two mockups.

All you have to do is check to see where you are in the category hierarchy to show products or

subcategories.

As Claudia reviews these mockups, she mentions that it would be nice to offer related items for any

product. You take this as your cue to start the process of creating a mockup for the Product Detail page.

Again, you use the shorthand rectangles that helped you create the home page, but this time you provide

space for a large product image, image name, longer description, and a “buy now” button.

“It’s not that simple,” Claudia says, reacting to your mockup. “We also need to provide other

information, such as colors and sizes. And I’d like to show related items off to the side.”

“What do you mean by related items?”

“Well, if they’re looking at a shirt, it would be nice to show some pants or shoes,” she says.

When you ask if these would be random selections, she says, “no”, that she would like to construct each

page like she does her store. In the store, she will routinely put together outfits, as doing it this way

increases her sales.

“Let’s do this,” you say, feeling a need to go away for a while to take better notes. “We’ll do a related

items sidebar, but it sounds like we need to figure out a way to group things together that doesn’t

involve categories. Something like a group number or something. Everything with the same group

number stays together.”

She nods and understands where you are going. She has other things to do, so she is also anxious to step

away for a while. As she looks at the mockup for the Product Detail page (shown in Figure 2-6), she

mentions how happy she is with the process so far.

Figure 2-6

“This is a lot more relaxed and visual than I remember from my high-tech days,” she says. “So far you

haven’t asked any scary questions, just about stuff that I know really well, like my business.”

You thank Claudia for her time and set an appointment for the next day, in which you’ll talk about a

“buy now” page and fill in some other holes in your knowledge.

Assimilating What You’ve Learned

Congratulations, you’ve done a whole lot of work. Not only have you created four mockup pages (home

page, category view, subcategory view, and Product Detail view), but you’ve also absorbed a great deal

of information about categories and products.

Here’s what you know about categories:

❑ Categories are hierarchical, but limited to two levels.

❑ Categories can be active or inactive.

❑ Categories have a name, a short description, and a long description.

❑ Images for categories are derived from the products assigned to them.

And this is what you know about products:

❑ A product can only belong to one category at a time.

❑ A product has a name, a large image, a thumbnail, a short description, a long description, and other possible metadata, such as sizes and colors.

❑ A product can be associated with other products to form groups or outfits.

 

Although not mentioned yet, one could correctly deduce that products can be active or inactive.

Something else not mentioned, but presumably a requirement, is that every product has a price

expressed as a decimal number.

Converting what you know about categories into a query that would create a table in MySQL, you

would have something like this:

   1: CREATE TABLE ‘categories’ (

   2:  

   3: ‘id’ INT NOT NULL AUTO_INCREMENT ,

   4:  

   5: ‘name’ VARCHAR( 255 ) NOT NULL ,

   6:  

   7: ‘shortdesc’ VARCHAR( 255 ) NOT NULL ,

   8:  

   9: ‘longdesc’ TEXT NOT NULL ,

  10:  

  11: ‘status’ ENUM( ‘active’, ‘inactive’ ) NOT NULL ,

  12:  

  13: ‘parentid’ INT NOT NULL ,

  14:  

  15: PRIMARY KEY ( ‘id’ )

  16:  

  17: ) TYPE = MYISAM ; 

  18:  

Similarly, converting what you know about products into a MySQL query, you would end up with the

following:

   1: CREATE TABLE ‘products’ (

   2:  

   3: ‘id’ INT NOT NULL AUTO_INCREMENT ,

   4:  

   5: ‘name’ VARCHAR( 255 ) NOT NULL ,

   6:  

   7: ‘shortdesc’ VARCHAR( 255 ) NOT NULL ,

   8:  

   9: ‘longdesc’ TEXT NOT NULL ,

  10:  

  11: ‘thumbnail’ VARCHAR( 255 ) NOT NULL ,

  12:  

  13: ‘image’ VARCHAR( 255 ) NOT NULL ,

  14:  

  15: ‘sizes’ ENUM( ‘s’, ‘m’, ‘l’, ‘xl’ ) NOT NULL ,

  16:  

  17: ‘colors’ ENUM( ‘red’, ‘blue’, ‘green’, ‘brown’, ‘white’, ‘black’ ) NOT NULL ,

  18:  

  19: ‘grouping’ VARCHAR( 16 ) NOT NULL ,

  20:  

  21: ‘status’ ENUM( ‘active’, ‘inactive’ ) NOT NULL ,

  22:  

  23: ‘category_id’ INT NOT NULL ,

  24:  

  25: ‘featured’ ENUM (‘true’, ‘false’) NOT NULL,

  26:  

  27: ‘price’ FLOAT( 4, 2 ) NOT NULL,

  28:  

  29: PRIMARY KEY ( ‘id’ )

  30:  

  31: ) TYPE = MYISAM ; 

  32:  

At this point, using an enum for colors and sizes is a bit iffy, as there may be any number of size

classifications (one for shoes, one for shirts, one for pants) and many different available color classes. But

for right now, this will do.

Of course, having mockups and some idea of what your MySQL tables look like is a good thing, but

before your next meeting with Claudia, you need to draw up a product backlog. The product backlog

will serve as a list of all the features you want to have in the resulting eCommerce web site.

Remember in the following discussion that there is a fundamental difference between the product you

are building (the eCommerce site) and the products in the actual store (shoes, clothes, etc.). As long as

you keep the two concepts straight, you’ll do fine.

Looking over your notes and mockups, you develop an initial product backlog based on successful

stories. A good story usually follows the pattern “As an X, I want to do Y, so I can do Z.” Here are a

few stories you can put in the product backlog — and please note that normally the product owner

would do this, but at this point it’s faster for you to set a precedent:

1. As a user, I want to view a featured product on the home page so I can buy it.

2. As a user, I want to view other related products on the home page so I can buy them.

3. As a user, I want to view a list of categories so I can navigate to those parts of the site.

4. As a user, I want to be able to navigate to Product Detail pages so I can buy products.

5. As a user, I want to see related products on a Product Detail page so I can complete outfits or

buy accessories.

6. As a user, I want to be able to see product thumbnails and images as often as possible to get an

idea of what the products look like.

This is enough for now. Tomorrow, you’ll meet with Claudia and she’ll take over the product backlog.