Category Archives: best of

The Best Agile Conference List On The Web!

Image From Chicago Scrum GatheringA great way to continue your agile learning journey is attending conferences. You’ll learn, build your professional network, and earn SEUs to renew your scrum certifications. To make the conference selection process easier, or harder, we’ve published the most complete list of scrum, agile, and agile adjacent conferences on the web.
Read the full article…

Share it!

Lessons From My First Failed Meeting

A bad meetingIt was a bad day at Geekaplex. A star developer’s computer had crashed hard, taking a week’s worth of new source code with it. The big boss was furious! I spoke up, “We need source control and a backup system.” The big boss looked at me and said: “Get some people together and make it happen!” I called my first-ever meeting and invited all of engineering.

Read the full article…

Share it!

Splitting User Stories with Acceptance Criteria

This is the fourth part of my series on splitting user stories. If you are just joining us, start with the first installment and work your way forward from there. Today’s technique is the third of four techniques to split user stories and it makes use of the user story’s acceptance criteria in order to split the story into smaller stories. What are acceptance criteria? Acceptance criteria are a list of pass/fail testable conditions that help us determine if the story is implemented as intended. Each user story should have between 4 and 12 acceptance criteria. The product owner works with the team to create, agree-upon, and record the acceptance criteria for each user story before the story enters a sprint.
Read the full article…

Share it!

Splitting User Stories with Generic Words

This is the third in my series on splitting larger user stories into smaller user stories. If you are just joining us, go back and read part one and part two. Don’t worry, I’ll wait right here for you.

Like the first story splitting technique (Conjunctions and Connectors technique), the second technique (the Generic Words approach) works by parsing the text of the user story. This time, instead of looking for connector words, we are looking for generic words. “What’s a generic word?” you ask. Any noun that isn’t a proper noun is generic, as are many verbs, adjectives, and adverbs. What we are looking for is a generic or general term in the story which could be replaced by several more specific terms to create a number of smaller stories.
Read the full article…

Share it!

Splitting User Stories with Conjunctions and Connectors

As I described last week, splitting large user stories into smaller user stories has many benefits for the scrum team and the business. We also agreed that before we try to split a user story, we want to write it in the traditional format:

As a <type of stakeholder>,
I want <the deliverable>,
so that, <some value is created>.

Read the full article…

Share it!

Introduction to User Stories and Splitting Stories

Text: Your stories are too big!A common problem among the scrum teams that I coach is user stories that are too big. When a user story is too big, it is hard understand, estimate, and implement. So what is a good size for a user story? My guidance is that the user stories at the top of the product backlog should be sized such that the scrum team could easily complete four to six stories a week.

When a team’s user stories are smaller, they complete stories more frequently. This is good on many levels. Each time a story is completed the team has delivered value, which is what the business pays us to do. We also get many types of feedback with each completed story. We can update our release (storypoint) burndown chart and get important schedule feedback, allowing us to inspect and adapt the schedule. We also get product feedback every time we finish a story. We have something new to show our stakeholders and they can give us feedback and guidance so we can adjust the product plan, to better build the product our stakeholders desire. Additionally, we get technical and architectural feedback. It isn’t until we have working user stories that we can see how well the technical and architectural choices we have made are serving us. If our original ideas are not working out as we had hoped, then we will need to adjust the architecture to better support the functionality being developed.
Read the full article…

Share it!

Paper Prototyping

LinkedIn has a cool feature that let’s you ask a question of your whole network. This morning, someone in my network asked this question:

Tools for visualising interactive prototypes? What do you prefer?

Powerpoint, ConceptDraw, Omnigraffle, Flash, Ruby on Rails?

We are reviewing the tools we are using to help visualise interactive storyboards and concepts for our clients. What are other people using? How important is it that the tool supports experimenting with real data and conditional branching in order to explore with the development team the consequences of their design decisions?

My reply:

Consider Paper Prototyping.

It is low cost, easy to do, and will quickly teach you how a real user will react to the system. With a paper prototype, a human acts as the computer, so your prototype can support some very sophisticated logic without the need to create code. Modifications are trivial, encouraging experimentation, discovery and improvement. I was skeptical at first, but after using it a few times I have become impressed with the power of this tool.

Photo courtesy of
Nertzy

Share it!

Compliments – Positive Feedback

Compliments and criticism are the two edges of the feedback sword. Today, The Chief Happiness Officer’s Blog explains that to be effective, compliments must be specific. This generalizes well to ‘feedback must be specific’. In particular, you want to clearly describe the behavior that you observed. For instance: “Bob, I see that while you were fixing that bug you also added several new tests and refactored the module.” Now that Bob knows exactly what you are going to compliment him on, tell him about the impact this will have: “That will really make it easier for people to work in that module in the future, and probably prevent some bugs too!” At this point, if we were delivering criticism, we would request a change in behavior. Since we are giving a compliment, we can simply say thank you: “I really appreciate you doing that. Thanks.”

You can find more on feedback here.

Share it!