<sigh/> Once more with feeling! Stories are NOT a code word for "a bit of work of some sort." A story is a few sentences that describe a user of your system performing some work that they find valuable IN THE DOMAIN. The are literally stories in the dictionary sense. 1/3
Stories do not describe a computer program. Stories do not describe programmer tasks or activities. They describe your user/customer's work, not yours. "Implementing a story" means that you do whatever you need to do to help the user get their tasks completed. 2/3
The point is to focus planning on value to the customer. You figure out your work—e.g. implementation tasks—just before (minutes) you start actually implementing. These tasks are not a story, nor are they any aspect of the story. 3/3

• • •

Missing some Tweet in this thread? You can try to force a refresh

Keep Current with Allen Holub

Allen Holub Profile picture

Stay in touch and get notified when new unrolls are available from this author!

Read all threads

This Thread may be Removed Anytime!


Twitter may remove this content at anytime! Save it as PDF for later use!

Try unrolling a thread yourself!

how to unroll video
  1. Follow @ThreadReaderApp to mention us!

  2. From a Twitter thread mention us with a keyword "unroll"
@threadreaderapp unroll

Practice here first or read more on our help page!

More from @allenholub

1 Jan
Let's start the new year with a rant on SAFe. (Hey, low-hanging fruit 😄). SAFe is a perfectly good process, but it's in no way an Agile process. We could start with "Individuals and interactions over processes and tools." SAFE is clearly very process heavy. 1/6
That comes with too much complexity, which flies in the face of "Simplicity—the art of maximizing the amount of work not done—is essential." Then there's "Responding to change over following a plan". Planning is a big part of SAFe, and the plans are much too long range. 2/6
The whole notion of a PI is a waterfall concept with an up-front plan. I could go on. SAFe violates most of the values and principles of the Agile Manifesto. 3/6
Read 6 tweets
6 Dec 20
I've seen two approaches for maintaining architectural integrity in a large system. One is the "architecture committee," which meets periodically and sits in judgment of all architectural changes. You can't make a change unless they approve. 1/4
It's a model built on distrust and the assumption of incompetence. I see no place for that in an agile organization. 2/4
Then there's the "guild" approach. The guild is made up of representatives from all the teams and one or two full-time architects. The entire guild makes architectural decisions. You go to a guild meeting to work collaboratively, not to get permission. 3/4
Read 4 tweets
6 Dec 20
Sometimes, a skill is specialized enough that it doesn't make sense to fully integrate it into a team. Take Architect. You don’t need one on every team, and in fact, a single Architect for an entire product helps with coherence. The architect has two main jobs. 1/7
(1) Diffuse their knowledge out to the teams, assuring that everybody has architectural skills at whatever level makes sense for them. They teach. They work with individuals. They review the team’s work & make suggestions. 2/7
(2) They work with all the teams for a given product to assure system coherence. They say things like “this is good, but if we do it this way instead, it will work better with what team 2 is doing.” 3/7
Read 7 tweets
3 Dec 20
IMO, the "Sprint" is one of Scrum's biggest flaws. Just dump it. When you're done with the current thing, metaphorically walk over to your backlog and pick the next-most-valuable thing to work on. There's a lot of waste in Scrum surrounding the packing of Sprints. 1/4
Getting rid of the Sprint gets rid of the waste. 2/4
That doesn't mean, by the way, that cadences aren't useful. Putting everything on the same cadence is not, however. 3/4
Read 4 tweets
11 Nov 20
I keep hearing about people who want to track the progress of an Agile adoption. What are you going to track? Agile is about "responding to change over following a plan." Tracking towards a goal implies an up-front plan and a definite destination. 1/4
There is no destination to Agile, though. It's a process. You constantly improve. You never arrive. 2/4
The way to keep improving is with a continuous-improvement culture, which is evidenced by things like regular retrospectives that come up with concrete improvements that actually happen. That's not the only way, though. 3/4
Read 4 tweets
10 Nov 20
I think it's worth distinguishing between a prototype and a mock up. The prototype is the first one. It's a test bed that engineers make changes to until they have the best results. The production versions are exact copies of the prototype. 1/4
I think of all software is a continuously evolving prototype. You never throw away prototypes. 2/4
A mock-up is not a real thing at all. It's something held together with duct tape and cardboard just to see if an Idea can work or not. You throw away mock ups. What people call "paper prototypes" are actually mock ups. 3/4
Read 4 tweets

Did Thread Reader help you today?

Support us! We are indie developers!

This site is made by just two indie developers on a laptop doing marketing, support and development! Read more about the story.

Become a Premium Member ($3/month or $30/year) and get exclusive features!

Become Premium

Too expensive? Make a small donation by buying us coffee ($5) or help with server cost ($10)

Donate via Paypal Become our Patreon

Thank you for your support!

Follow Us on Twitter!