Your bio establishes your expertise, authority, and credibility in your field. If your conference proposal has a speaking experience field, use that field to explain your expertise, authority, and credibility. I like to think of the bio and speaking experience fields as ways to connect with and invite the right people to your session: These […]
You know who your audience is because you framed the proposal. You started with outcomes, and you refined those outcomes when you wrote the abstract. Now it’s time to complete the rest of the proposal, excluding your bio and the title. Bios and titles are different from the rest of the proposal. (Those will be
You decided who your session is for: the people with the problems. You’ve got the outcomes. Now, it’s time to write the abstract. Conference proposals always have a short abstract. Some conferences, such as the Agile 20xx conferences, also have “Information for the Program Team.” You might think of that as the outline or more
Now that you’ve framed your proposal, start with what you want people to take away from the talk, the outcomes. Why? Because too many descriptions are a promise for an outcome or what people will learn. If you’re coy about the outcomes, people can’t select themselves in or out for your presentation. Speakers who say,
You want to present a talk, workshop, experience report at a conference. (Or, a lightning talk, Pecha Kucha, or more.) You have something important to share. How can you create a proposal that the program committee will accept? I’m writing this series to explain how to do just that. The series parts are: Understand who
I spoke with an agile coach whose team works in flow, similar to this board. They don’t use iterations—they plan on demand. The column on the left, “Stories to Workshop” is their backlog refinement column. Recently, the team decided they need “minimum” WIP (work in progress) limits. Especially on the Workshop column. Why? Their product
If you are like most people I know, it doesn’t matter what approach you take to your projects—your manager has too much work for you to do. Instead of a potential career-limiting conversation, frame the conversation so you can show your manager you’re considering his or her perspective. Here are some options for how to
Shaun’s comment on Measure Cycle Time, Not Velocity suggested a team might be better off measuring both cycle time and velocity. Why? For two reasons: “Beating” the last sprint goal Assisting the PO in a forecast of when things might be done. Let’s examine these ideas. Clarify Story Points Why even bother with story points?
I’m not a fan of measuring velocity. Velocity is a point-in-time measure of capacity. That means that when things change for the team or in the code, the velocity often changes. (See Velocity is Not Acceleration.) Instead, I like to measure cycle time. Cycle time is the entire time it takes a team to finish
Does your team have to keep two sets of “books”? You have an agile roadmap to see where you’re headed. You have a smallish backlog of the near/upcoming work. You’re delivering on a frequent basis. And, someone on your team keeps a Gantt chart because a manager wants to see the team’s progress in a