以「蜘蛛法」拆分過於龐大的 User Story

(改寫自公司內部 memo)

   

Hi all guys,

剛從傳統瀑布式專案管理風格轉換到敏捷風格的團隊,最常遇到第二個卡關之處是:如何將 User Story 拆分到足以在一個 sprint 內完成的顆粒度?

如果玩過我帶的「在幾分鐘以內出門」(“get out of the door in a few minutes”) 活動 1,或許可藉由喚起這段活動的體驗來得到拆分大故事的靈感。如果還想進一步知道更具體的步驟,我推薦大家試試 Mike Cohn 大師提出的 SPIDR 法

事情做一半,等於沒完成:淺談敏捷的里程碑設定

(改寫自公司內部 memo)

   

Hi all guys,

剛從傳統瀑布式專案管理風格轉換到敏捷風格的團隊,最常遇到第一個卡關之處是:如何以敏捷的角度設定里程碑?

最近在協助兩個 Scrum teams 進行 Sprint Planning 時,我都會用以下角度提出挑戰性提問:

  • 能否將 User Stories 拆分到:可以在一個 sprint 結束時,端出利害關係人可以據以給出建設性回饋end-to-end 成果

這需要創意,需要練習,需要提升規劃能力,需要提升工程能力,需要時時用挑戰性提問提醒自己。但或許更重要的是:大家需要打從心裡認清且認同這樣做的理由。

理由之一是:精實生產。

User Story 釋疑:真的要遵守嗎?

(改寫自公司內部 memo)

   

Hi all guys,

最近我會對有意導入 Scrum 的任務小組個別進行一整天的 Agile Workshop。這些小組都有一項課前作業:請先準備團隊在三個月以內會進行的 User Stories 清單/陳述。

眾所周知,user story 有一個經典句型:

As a {XXX user persona}, I want to {do YYY} so that {ZZZ result or benefit}.

有同仁問道:有些 user story 不容易以「“user” 視角」來寫。怎麼辦?真的要這麼嚴格遵守 user story 格式嗎?

職涯躍升書系導讀會,Part 2:高效團隊的工作方法

2022 年一月起,我開始每個月一次,每次兩小時的【職涯躍升書系導讀會】。前六個月著眼於喚醒個人及團隊的成長意識,接下來兩個月則著眼於高效團隊的工作方法

這兩個月的導讀會,都鎖定在 Agile 相關書籍上——儘管單純從書籍名稱上面都看不出來會與「敏捷」有關。選書如下:

以下列出這兩場導讀會的介紹文案。

請掌握「對高層簡報」的技術及習慣

(改寫自公司內部 memo)

   

Dear all guys,

最近協助一些同仁潤飾簡報,尤其是對高層的簡報,有一個常見的問題,值得特別為文給大家一點建議。

我們在三月份導讀會不懂這些,別想加薪》就已經探討過,對高層的寫作與簡報,要盡量掌握「金字塔原理」:結論先行,論證隨後。

鑑於有些人沒參加這場導讀會,以下僅說明三大重點:① 一般的溝通原理,② 對高層的溝通原理,③ 對高層的溝通方法。