Continuing with the  100 Things You Must Know to Be Effective In Software Development. Scrum talks about self-organizing, cross-functional teams. Let me make it clear, this is the best team structure I know.  Some folks have construed this to mean - teams of generalists.  That is not what it means.  It means the team has all of the skills and knowledge required to create valuable software....

[[ This is a content summary only. Visit my website for full links, other content, and more! ]]

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.

Let’s look at an example. Here is a user story:

As a couple,
we want a romantic dinner for two,
so that we can have a date even more romantic than our first date

Here are some acceptance criteria for this story:

• There are 2 lit candles and fresh flowers on every table
• The main course offerings include steak, fish, and at least one vegetarian option
• There are at least 2 kinds of red wine and 2 kinds of white wine available, as well as a Champagne
• There is a string quartet or a piano player playing soft instrumental music
• The waiters are wearing tuxedos

If we examine each one of the acceptance criteria, we can ask “Who wants this?” The answer to this question becomes the user in “As a (type of user).” Next, we ask “Why do they want that?” The answer to this question identifies the value in “so that (some value is created).” The body of the acceptance criteria provides the “I want (something)” part, and now we have all three parts for our new user story:

As a (type of user),
I want (something),
so that (some value is created).

Here are user stories that could be derived from the acceptance criteria above.

As a couple on a dinner date,
we want candles on the table,
so that the mood will be more romantic.

and

As a diner in the restaurant,
I want to be able to choose from steak, fish, and at least one vegetarian option,
so that I can order something that conforms to my dietary and flavor preferences.

and

As a wine lover
I want at least 2 kinds of red wine, 2 kinds of white wine and 2 Champagnes available,
so that I can choose a wine that will go well with my meal.

and

As a couple on a dinner date,
I want to hear instrumental music from a string quartet or a piano player,
so that the mood will be more romantic and I can still converse with my date.

and

As a couple on a romantic dinner date,
I want waiters that are wearing tuxedos,
so that we can feel like we are at a classy restaurant.

Using acceptance criteria to identify smaller sub-stories is very handy and powerful, because it is recursive. Every story needs acceptance criteria, and many acceptance criteria can become their own smaller stories. Of course, each of these new small stories needs to have acceptance criteria. And, we could use these acceptance criteria to break the stories down again. It’s turtles all the way down!

Tune in next week for the final installment in Splitting User Stories.

Here are quick links to all of the user story splitting posts.

• Introduction to User Stories and Splitting Stories
• Splitting User Stories with Conjunctions and Connectors
• Splitting User Stories with Generic Words
• Splitting User Stories with Acceptance Criteria
• Splitting User Stories with Timeline Analysis

Cheers,

Chris

Chris Sims is co-author of Elements of Scrum as well as a Certified Scrum Trainer, agile coach, and recovering C++ developer who helps software development teams improve their productivity and happiness.

The post Splitting User Stories with Acceptance Criteria appeared first on Agile Learning Labs.

Selecting the right items for an agile project to work on next is vital to ensure your team is delivering the maximum value possible to the business. Rather than "MoSCoW" (see recent post) or similar prioritisation schemes, +David Anderson's Kanban book recommends using the opportunity-cost of delay as the way to decide which items to pull next (or which items to put into the next sprint if you're using Scrum). He suggests 4 archetypes for categorising what the cost of delay might look like, when the impact (opportunity cost) is plotted against the time of release:


Expedite items have a high and immediate cost of delay. They should be started at once and given priority over other items. Fixed date items have a high cost of delay once a threshold is passed. They should be started before there is a significant risk this date will not be met. Standard items' cost of delay follows a fairly shallow S-curve, in other words, there is no reason to expedite them - they should be handled normally. Intangible items apparently have no immediate cost of delay, though it is expected to rise at some more distant point in the future. Such items are useful background tasks to be handled when there are no more urgent tasks.

At a recent Kanban Masterclass I attended, David introduced an example to demonstrate the difference between Fixed Date Items and Standard Items:
A hotel/resort site wishes to offer two special promotions: one for the Spring/Easter holiday; one for Valentine's Day. Because people tend to book much later for Valentine's Day, the opportunity-cost of delay is likely to be much "steeper" - more like the Fixed Date case, compared to a more "Standard" shape for the other promotion.
This led to consideration of what the revenue projections for different release dates might be in these 2 cases, so I undertook to produce some sample data for discussion. Here they are.


The graph above shows the imagined additional sales generated by launching the Easter promotion on the dates shown. There's no point in launching before Christmas and New Year are over (zero cost of delay), so the first release date is January 1st. There's an initial bump when the first ads go out, then a growth in revenue, and in this case a rapid drop off when it is anticipated all places will be sold. Later releases follow a similar pattern but after 5 or 6 weeks' delay the cost in lost sales becomes much higher as sales go to the competition or simply have insufficient time to close.

The graph above plots the loss of revenue of the early February release (5 weeks delay) compared to 1st January release. Sales are always behind - even after the slight recovery in the period after the January release has sold-out.

Taking all the potential release dates and plotting the opportunity-cost for each delay produces the graph above - an S-curve showing little impact initially, rising more rapidly after the first couple of weeks.

Let's compare that with the simulated data for the Valentine's promotion.


In this case we are expecting nearly all the sales to be made in the last couple of weeks before the event. It really doesn't help to launch early because people won't book early any way!


So plotting the cost of delay in this case we get a curve which is much closer to the archetypal step function of the Fixed Date items. If there are items with higher opportunity cost of delay early on in the year, it is more beneficial to do these items, provided we don't miss the late January release for the Valentine's promotion, i.e. the point where the curve hits the "hockey stick" upwards.
Hopefully these examples help the understanding of the concept of using cost of delay for deciding which item an agile team should do next. Let us know if you have any real data examples to demonstrate this concept. I'd be most interested to hear about them.

More than 1,000 developers across 72 events will join together on June 1-2 for National Day of Civic Hacking. Their mission? To use publicly-released data, and code to solve challenges relevant to our neighborhoods, our cities, our states and our country.

Here are 10 reasons why you should join:

1. Make a difference while building your local Agile and open source community
2. It’s only one or two days! And it might also open minds, hearts and doors to work that extends us beyond all of our “day jobs”
3. 24 data feeds and 17 federal government partners will lead to some great hackathon magic
4. President Obama and Todd Park, National CTO, are opening the White House for hacking via a lottery, and as a demo platform for the best applications
5. All this work will help the government open more data and thus create a better informed public
6. Tim O'Reilly will be proven as a prophet and general good guy for helping promote open source, open data and hacking for the last decade 
7. Get $200 off your registration for our RallyON conference by joining us to hack with the team from the National Renewable Energy Lab in Boulder
8. Your volunteering opens your eyes to the role of citizen engineers in solving the world’s toughest problems
9. Don’t have an event near you? Join a Rally team remotely using FlowDock and AgileZen
10. Support a culture of hacking that can lead to continuous innovation in your own organization

As part of our Rally for Impact efforts to help create and mobilize citizen engineers that are technically, environmentally and socially responsible, we are a proud sponsor of the National Day of Civic Hacking. Thanks to organizers like Code for America, Innovation Endeavors and Random Hacks of Kindness. And thanks to the organizational skills built by Second Muse, sites are finding great local and state resources.

Please consider joining, sharing and re-posting about National Day of Civic Hacking in your company and community

Join us in Boulder, CO to learn from industry experts and peers, hear what's next for Rally's product suite; and have a little fun while you're at it!

Schedule of Events

RallyON Hackathon
Fri - Sat, May 31 - June 1
National Civic Day of Hacking
Sat - Sun, June 1- 2
RallyON! Conference
Mon - Wed, June 3 - 5

Ryan Martens

I formed LKU as an equal partner with David Anderson in 2011 with high hopes of an organization that would manifest the values of industry service, thought leadership and inclusion.  I envisioned it as a place to provide industry awareness of the value of Lean and Kanban, a listing of courses on Lean and Kanban, and as a way of identifying those truly experienced Lean and Kanban trainers and...

[[ This is a content summary only. Visit my website for full links, other content, and more! ]]

Scott Turnquest

Companies rarely promote people into leadership roles who haven’t been consistently seen and measured. It’s a familiarity thing, and it’s a trust thing. We’re not saying that the people who get promoted are stars during every “crucible” moment at the office, but at least they’re present and accounted for. And their presence says: Work is my top priority. I’m committed to this company. I want to lead. And I can.

- Jack and Suzie Welch in a 2007 Business Week column 

After all the hullabaloo about Yahoo eliminating its work from home policy I thought a lot about how distributed work is part of everyday life on many ThoughtWorks teams. It’s certainly true for our Mingle team where we have a pair of great developers who are based in the UK while the rest of the team is based in San Francisco.

Thumbnail: 

read more

Yesterday, this report showed only a daily cumulative quantity of tickets, we have improved upon it.

Do you use estimates on your daily work? - Good news, today you can choose "Ticket Estimate" from the “Type” select box.

 

You will be able to see the same Cumulative Flow chart, but this time you will see the sum estimation of your tickets (per status).

Which type of Estimating do you use?

• Do not use estimates: Default estimate value is 1.0, so you will get the same graph as Ticket Count.
• Show estimated total time: Estimate value is saved as a float value representing the total time, you will see a cumulative report of tickets total time.
• Show estimated points: In this case you can manually set points to each ticket, the result will be a summation over time of points in tickets.
• Estimate as T-Shirt sizes: (Small / Medium / Large): Same as estimated points but with predefined values.
  • Small => 1.0 points.
  • Medium => 3.0 points.
  • Large => 7.0 points

We have been collecting this data for a week so far - full month Cumulative Flow Chart will be available in three weeks. If you use estimates on tickets, then this upgrade is for you. Enjoy!

Read more about how Assembla can help You.

Continuing with the  100 Things You Must Know to Be Effective In Software Development. If you read day 1, you knew what was coming today.  Acceptance Test-Driven Development is one of the greatest trim-tabs of software development. ATDD is one of the most powerful, easiest to introduce practices available.  It is about making sure you know what you need to build before you build it.  It has a...

[[ This is a content summary only. Visit my website for full links, other content, and more! ]]

It's been just over a week since Rally's IPO on the NYSE under the symbol RALY. We're settling back into our everyday work, and as I look back, I am again humbled to be one of the companies that trade in the public markets, and proud to be listed on the NYSE.

The morning of our IPO, I got to see Rally's logo on the front of the iconic NYSE building, I stood on the bell podium and pushed a giant green button with our founder Ryan Martens. And I toasted (with orange juice) enthusiastic employees in their offices around the world live from the bustling trading floor. 

But what struck me most throughout that day, and the days following, was the gratitude I felt. Tremendous gratitude. 

Thank you, Rally team. Rally is made up of individuals who are smart, committed and passionate. I am humbled that I get to come to work with you every day.

Thank you, customers. We work with and constantly learn from our customers and users. We continue to look to our customers as guides and partners, many of whom are helping redefine their industries through innovative software-powered products and services. We dedicate our success to date and our focus into the future to them. 

Thank you, partners, vendors and community members. Rally's ecosystem is strong and vibrant, and I know we are lucky to have those support systems all over the world.

In the midst of a lot of really hard work, we've had some fun and celebrations over the last week or so. Below are some of my highlights:

Here is a video of the NYSE opening bell ceremony:

Later I was proud to represent Rally, and our customers in talking with the media about a very special day for our company. Here's one take by our Boulder, Colorado-based Daily Camera.

Most fun for me as someone who values our culture so highly, here are a few photos of our employee celebrations that took place nearly simultaneously around the world.

Thank you for joining us on this journey, it's been – and will continue to be – a great ride.

Tim Miller

I had to think a bit on what to have be #1.  Was it something on Acceptance Test-Driven Development, one of the serious trim-tabs of software development?  Or be the underlying reason that drives Lean and Agile?  I ultimately picked How Delays Induce Work (don't worry about the title of the article that is brought up being different) because it is the underpinnings of Lean.  When how delays cause...

[[ This is a content summary only. Visit my website for full links, other content, and more! ]]

Back in the mists of time (some time in the last century) DSDM came up with a neat acronym for classifying the importance of requirements, MoSCoW - meaning a requirement was one of:

• Must-Have
• Should-Have
• Could-Have
• Won't Have (even if you Want it!)

The problem with this scheme has always been getting stakeholders to specify their requirements as anything other than Must-Have and Project Managers to resource their projects so that there's anything other than barely enough time for the mandatory requirements. Just like my old boarding school - if it wasn't compulsory it was forbidden. Many agile practitioners have concluded that schemes like this which give user stories a priority value or category, are not worth the effort - just get the product owner to identify the next most important stories and we'll prioritize the other requirements later. I sympathise with that view but on a previous project I needed a way to introduce the idea of a "scope range" for each release of the software, and to do that I redefined the meanings of the MoSCoW categories.

Firstly Must and Won't:

Must-have (this release): If this functionality is not available by the release date, the release will be delayed.
Won't-have (this release): If all the other functionality is complete before the release date, we'll release early rather than start this work.

Should-have and Could-have both mean they will be attempted for the release if there's time. The difference between them is whether our forecasting predicts that it is more or less likely that they will make it. Thus:

Should-have (this release): Our forecasting shows a greater than 50% probability that the functionality will be included.
Could-have (this release): Our forecasting shows a less than 50% probability that the functionality will be included.

I felt this was a stepping stone for the client, to move away from deterministic and towards probabilistic planning. The main problem with the approach was that I was re-using a scheme that already had a publicly available definition and so in a large organisation there was no guarantee people would be using the definitions I had introduced.

A better approach now is to look to schemes based on the cost of delay of requirements. This again emphasises the probabilistic nature of forecasting and uses flow data from the process to optimise costs.

I have been in software development for almost 43 years now.  This doesn't mean I'm smarter than anyone, it just means I'm older, er, I mean I've seen a lot..  One thing I've seen repeatedly is arguments and discussions about how to do things.  Re-entrant code in the 70s, structured code in the 70s as well.  4th generation languages in the 80s, object-oriented code in the 80s and patterns in the...

[[ This is a content summary only. Visit my website for full links, other content, and more! ]]

A few years ago I was asked by one of our customers to help them make better use of their integration layer. Ever since then me and my team have been working on a framework in support of that. This is the fourth in a series of blogs on the development of our framework, and discusses the features it provides. The one that was announced last time, about building blocks, is momentarily postponed.

So far I’ve discussed the goals & challenges surrounding the development activities, but I’d like to focus more on the framework itself now, and what it brings to those that are using it.

As soon as a new party (be it service consumer or service provider) connects to our framework, it can profit directly from the wealth of functionality we deliver out-of-the-box. These ‘generic features’ are exactly what one would expect from a (logical) ESB, and are partly based on the Expanded Enterprise Service Bus Pattern.

As our project was scrum driven, features were developed only when they were needed. Sometimes, during the design & build phase, we discovered a better way of doing things, and sometimes the problem a feature was supposed to address was solved in a completely different way, outside of our scope. But in the end we managed to implement about 20 features, which can roughly be divided into five types: routing, robustness, security, transformation and data storage.

Routing

One of our main objectives is to get messages from A to B without A having to know where B is currently residing. To do this, we make extensive use of the WS-Addressing standard. One of the components in our framework, the routing service, uses the information in the message headers to decide what the next hop will be (hop in this case being another framework component). Most of the times a message is delivered to the backside as soon as it enters the integration layer, something we call simple routing.

However, as soon as some special activity needs to be performed (like data model transformation for example), the message is detoured to one of the framework components not connected to the outside world. We classify those as intermediate services, and they are agnostic of nature – which means they have no clue about the context in which they are called. The necessary information for the message to continue its path is part of the addressing headers as well, making this advanced routing.

A special kind of advanced routing is distribution, which makes it possible to send one message to several subscribers at the same time, using WS-Notification in its most basic form. Finally prioritized routing is a feature which makes sure that a message gets ahead of the rest so to speak – very useful when dealing with a customer waiting for service at a counter while there’s also a bulk load being processed.

Robustness

Of course it’s of eminent importance that nothing goes wrong when delivering the message, or that when it does we can at least deal with the situation (exception management). First thing that happens when we receive a message is that we check to see if it complies with the industry & design standards we enforce (technical validation). Sometimes the consumer/publisher doesn’t want to wait for the (functional) answer but still wants to be informed if his message was technically valid, in which case we send him a response stating just that (technical acceptance).

Two of our features deal with peak load: throttling makes sure the integration layer only takes in what it can handle, while buffering guarantees we don’t overwhelm the applications we connect to. Similar to the second one is postponed delivery which is used when we know beforehand the backside is not available.

But by far the most important of these types of feature is guaranteed delivery. We played around with a bidirectional variant (using WS-RM) but finally settled on an unidirectional implementation, meaning that before we send the message we first store it, and if we receive an HTTP error code we send it again.

Last (and actually least, as it’s hardly used) it’s also possible to have syntactic validation of outgoing messages. But as we like to follow Postel’s law (also known as the robustness principle) we feel it’s the consumer’s responsibility to make sure the message was valid to begin with (you can imagine this took some selling from our part). The only exception is when the payload is altered by the framework.

Security

Every application that wants to connect to the integration layer needs to make itself known using the WS-Security UsernameToken (authentication). For most of the services we expose that’s enough, in a few rare cases such an application has to have explicit permission (authorization).

Not used internally (only when we receive requests from certain external customers) is integrity, where we demand that certain parts of the message headers and payload are signed.

Transformation

Given the fact that not all applications connected to the framework ‘speak the same language’ (as mentioned in the previous blog), there’s an evident need for data model transformation – one of our most used features. A lot less popular is the split feature, which makes it possible to divide a big message into smaller parts.

Data storage

The last few features play a more supportive role to the ones already mentioned. We provide logging to be used during testing & bug-finding sessions and persistence when there’s a need to store the complete message. The latter is frequently used in combination with resending (which is necessary for the guaranteed delivery feature described above), but also in case of auditing requirements.

Conclusion

Most of these features have been around since the first version of our framework, and have proven their generic qualities over time. In a few cases we had to make some alterations and even now there are one or two features which we might implement differently in the future. There’s also a list of additional features but it’s rather short, which I take as a sign that what we have here is pretty complete.

That’s number four; next time I’ll talk a bit about the more specific deliverables we provide our project teams.

My number one favourite? Not estimating them at all! 

Instead, ensure stories do not exceed an agreed size that ensures they fit easily within a sprint (ok - I agree that's estimating, but it's much simpler estimating than tee-shirt sizes (S, M. L or/and too big) or points (1, 2, 3, 5, 8,  and too big). Then spend the time you've saved estimating the size of stories on estimating the number of stories in the various epics in your product backlog. Measure velocity in stories not points (or use only two sizes: 1 point and too big) and forecast the completion of epics and minimum-marketable-features based on the throughput of stories (velocity) and the number of stories. 

As well as saving a ton of time, it turns out your forecasting will be just as accurate as if you'd spent ages agonizing over each story! See for example +Vasco Duarte's blog about the evidence for improved forecasts from this approach.

The key question - as +Neil Killick points out in his recent "People Need Estimates" - is what problem are we trying to solve with our estimating? 

I was working with a team recently who were concerned that they had missed their forecast for the second sprint in a row. The retrospective meeting came up with several suggestions about how they could improve their forecast for the next sprint. I asked the team whether there was anyone (outside the team themselves) who was interested or concerned about their forecasting ability. The last few sprints were running at a throughput that was over double the average for the previous year. If the team continued to focus on the improvements they were making, the business could easily adjust to this higher efficiency. The business did not need (or probably believe) the over-optimistic forecasts that the team were making. Shown the evidence of actually completed work, the business will adjust to the new opportunities the improvements open up.

Sriram Narayan

Say we have a set up like the one below. We have two pipelines -- one for component-1 (C1) and another for component-2 (C2). C1 just builds off its source code in version control (VCS-1). C2 has its source in a different repository (VCS-2) and is also dependent (d3) on C1. In Go terminology, C1 has one upstream dependency d1 while C2 has two upstream dependencies d2 and d3.

Thumbnail: 

read more

I always have a backlog of non-fiction books to read. Given the amount of free time that I have every day, I am guessing that it may be years before I get through them. In fact, the rate at which books get added to my backlog probably exceeds my learning velocity, creating an ever-increasing gap. It feels like a microcosm of Eddie Obeng’s “world after midnight.”

So what to do?

I am trying to increase my velocity by applying speed reading techniques. But so far, that is probably only closing a small percentage of the gap.

Iterative Learning

Then, upon a bit of soul searching, I had an epiphany. Why do I feel the need to read and understand every single word on every single page? This runs counter to what we coach our teams to do—eliminate waste, only document what makes sense, just-in-time practices, and applying iterative thinking instead of only incremental. The answer seemed to be that I don’t feel that I have really read the book if I haven’t read every word. So what? Am I trying to conquer the thing? It seems like a very egocentric point of view.

What if I was able to let go of the ego, and try to read a book iteratively instead of incrementally? Is it even possible? Would it be effective? There are all sorts of ways to tell stories or build products—top-down, bottom-up, inside-out—each of which have their strong points. Sometimes it is most effective, for instance, to grab the user’s attention by initially giving them a nugget that might logically be placed in the middle of a narrative, and then providing necessary foundation, or by filling in the gaps as necessary. Could one apply the same process to learning from a book? I could imagine scanning through a book randomly, stopping at points that looked interesting and digesting a bit—much like I used to do with encyclopedias as a kid. Or, maybe, first reviewing the TOC for areas of interest, jumping to those sections, absorbing a bit, and then searching for any context that was missing.  This would be a completely different way to learn from a book. I couldn’t call it reading, and don’t have a good term for it, other than a new kind of learning.

This led me to thinking a little more deeply about what I am trying to get out of reading; the learning aspect of it. What if I could scan a book in a tenth of the time that it took to read it, but retain half of the content? Would that be an improvement? There seems to be some sort of formula that I am trying to maximize, like dl/dt=CVR: Rate of learning equals the “learn-worthy” content of the book multiplied by the speed that I scan it multiplied by the percent that I retain. Is the percent retained equal to the percent value obtained? Do I get half the potential value of a book if I retain half as much? I could simply define R to be the percent value and my equation still holds. Something in the back of my mind says this it is really sad to look at learning this way. Something else says I am on to something.

Of course, there are all kinds of nuances.  For example, some books build upon a foundation which must be well understood to get any value at all out of the latter sections of the book.  For others, it may be easier to skip around. Some, you may be able to get value out of scanning the TOC, or the subheadings, digesting the graphics, or just reading the intros and summaries of each chapter; for others, not so much.  Hence, in a sense, different books have different learning profiles.

The Experiment

I was intrigued enough to attempt this on a book near the top of my backlog: Steven Wolfram’s A New Kind of Science, a 1280-page tome that took him ten years to write. So I did it. I didn’t “read” it. I iterated through it and digested some of it. And can honestly say that, for this particular book, I optimized my learning rate equation significantly. I can’t be sure of the total potential value that the book would have to me were I to read it in its entirely, but from what I digested, I feel like I got about 50% in about 5% of the time—a tenfold increase in my learning rate. And Steven got his royalty. Yes, I do appreciate the irony of using a new kind of learning on A New Kind of Science. And letting go of the idea of conquering a book was kind of liberating.

So, what if we look at a particular learning objective in the same way that we manage a large project or program? I am imagining a vision or an objective like “I want to become learned in Digital Philosophy” (one of my particular interests.) That vision results in the creation of a backlog of books, papers, blogs, etc. The larger of these (books) are epics and can be broken down into stories, like “Scan contents to get a sense of the material,” “Determine the core messages of the book by finding and reading the key points,” “Understand this author’s view on this particular topic,” and so on. By thinking about learning material this way, it opens up all kinds of new possibilities. For example, maybe there is another way to slice the backlog, such as by topic. If the most important thing to further my overall objective is to understand everything about cellular automata, I would assign higher priority to the stories related to that topic, even if they come from separate sources. So, my learning process takes a different path; one that slices through different material non-linearly.

Lean Startup Learning & Continuous Improvement

In fact, this all feels a bit to me like a lean startup approach to learning in that you can experiment with different chunks of material that may point you in different directions, depending on the outcome of the reading experiment. Having a finer backlog of reading components and being willing to let go of the need to conquer reading material might make possible a much faster path to an ultimate learning objective.

And so I am passing along this idea as an option for those who have a voracious desire to learn in this after-midnight world, but have a before-midnight backlog of reading material.

The post An Experiment in Learning, Agile & Lean Startup Style appeared first on BigVisible Solutions.

Huimin Li

He who travels light, goes far.

                 -- Chinese proverb

Does this kind of conversation sound familiar to you?

Customer: I want abc, because xyz.

Product team: Sorry, we don’t have it now, but I’ll add it to our backlog.

This comes up for me frequently on the Mingle team. We carefully capture all requests and spend time to follow up on each one.  However, with each request, the queue keeps getting bigger. 

Thumbnail: 

read more

Roy van de Water, Jade Meskill, Derek Neighbors, Clayton Lengel-Zigich and Mike Vizdos discuss:

• Lean Startup in the enterprise.
• Vanity metrics
• LeanPub
• Mike’s Childrens Book

What is a Paradigm?

While there’s been some talk and research about project management paradigms e.g. waterfall, Project Management 2.0, ALM,  with the paradigm of agile prevailing at the moment,  looks like no one has spoken about the paradigm of project management tools.  What is a paradigm, in general? It’s a system of principles that unveils the essential qualities of a subject in their entirety. From this perspective, a paradigm of PM tools would be a spot-on framework for choosing a PM tool.  To make it more clear, a paradigm is something that allows a complete 360° view on any subject or matter. I’d say it’s not about the flat 360° view as in traditional geometry, but about a multi-spherical 360° view, as in the geometry of Lobachevsky. In linguistics, a paradigm is a complete set of all the forms of one and the same word realized  through declension and conjugation, esp. as in German or in Russian. A paradigm represents the system of approaches to unfolding a phenomenon. Musing about the cross-disciplinary nature of paradigms, how can we apply it to the project management tools, and how can this concept help software developers?

A multi-spherical abstraction

A Basic Paradigm: MS Project and Excel

I’m sure most of the readers have been facing the moment in their professional life, as they needed a tool for project management. Historically, most of us stem from MS Project and then Excel. MS Project served quite well as a clock ticker for the work that’s planned ahead and progresses exactly as planned. For waterfall, this narrow paradigm worked OK, assuming the project is flat and linear.

What changes in agile software development? The project management paradigm shift  means that nothing is ever going as planned. The PM tools should undergo a shift as well, from routinely tracking the progress the way it’s been planned, to dynamically sensing trends and registering hands-on performance indicators. Sounds like something familiar? Very close to stock trading, that’s right… and we’re still amazed at how many teams keep using Excel for agile project  management. Well, there’re some down-to-earth reasons behind this. Excel comes as a part of the MS software suite, and there’s no need to pay extra for it. One can put data to Excel, and even use it for planning, tracking and reporting. But there’s one essential flaw with Excel. It isn’t a shared collab tool, someone has to keep this Excel file, and while Excel shows statistical trends quite OK, as for stock trading, but it takes habit, skills and extra time to tune it as a decent trend-revealing tool for agile project management (and I’m not even talking about UX and visualization so far).

Excel used in stock trading

The Incomplete Paradigm: Beware Flaws in Assessment

There’re many project management tools out there. Tons of them. It’s not easy to navigate in this space, and when someone is looking to select a PM tool for their company, they  use some typical research methods… and bump against the same misconceptions.  Let me give a brief outline of some approaches that I consider counterproductive.

First, it’s following a direct pitch. Remember, what happens when someone throws a link at you and says “this tool is just what you need”? By “someone”, I mean people who send haphazard intrusive pitch messages either directly to your email, or in social networks, etc.  Normally you’ve got work that needs to be done right now, and you don’t want to interrupt your flow and switch to studying how this tool works, although it might promise a whole new world of  miracles. Next, you have no idea if the person who throws the link  is aware of your needs. It’s easy to throw a link at someone, but it’s not easy to decide for another person if that’s what they need. OK, you might be tempted to open the link to take a look, and invest some time in studying what it’s about. After taking a quick look, you decide that  the pains from using your old tool do not outweigh the trouble and time that you need to invest in exploring this new tool, and you stay with what you have. That’s why following a direct pitch is the least likely way to find what you need (and from the marketing standpoint, the direct pitches are rarely successful).

Second, it’s PM tool assessment sheets. I’ve worked with the leads and clients for quite some time, and what I’ve always been amazed at, that even until recently people have been using those cranky assessment sheets, that should be filled “yes/no” for random standalone aspects which would never put together the complete picture. Like, what changes if we put checks in all the boxes that say “collaboration”, “issue tracking”, “scheduling”, “portfolio”, “resource”, “document management”?  Such assessment sheets are clueless. They still give no clear picture of how the tool works, and whether it will address whatever needs and pains of this very company. The feature requirements as in those sheets  remind me of the flat geometry confined to the 2D surface. Somehow, they never have such bullets as “good data visualization”, “speed to change contexts and retrieve any data”.  That’s an apparent disconnect, where the task of selecting the project management tool is given to an administrative employee, and the real stakeholders, the people who will be working with the tool are left out of the initial screening stage. Well, might be that their process has the stakeholders engaged later, but why not then take a step of extra care to save the stakeholder’s precious time and add a few human requirements?  Like, how human-friendly the tool is? Is it easy-to-use? Still, as much as I’m a wordsmith, I have to admit that no words in no assessment sheets will replace the actual feel and sight of a project management tool in action. The complete paradigm of PM tools is supposed to cover all the facets of multi-dimensional chaotic project management, including the human aspect. How about introducing the criteria of learning curve – simplicity/complexity – user background vs. ease-of-use? One can’t make an accurate assessment of those qualities from “yes/no” sheets.

The third most common misconception is related to all the buzz around agile, agile training, agile consultants, “we-should-do-agile-coz-everyone-is-doing-it”, etc. It’s about hearing of the agile adoption, and rushing to get an agile PM tool, instead of taking care of the process first. This is the same as the phenomenon known as Gear Acquisition Syndrome among musicians, when instead of actually playing music people focus on acquiring lots and lots of music gear.

How much G.A.S. is enough?

I believe that if a company is building their agile dev process from within, they acquire their unique corporate expertise which is an asset in itself. It’s this unique expertise that finally helps them run projects with success and use the tools they need. Same with the GAS syndrome: you don’t know if you like this guitar until you play it. You can watch how a local  pro makes it out with the instrument in the show room (that’s what consultants do), or you can  try and play yourself to get the actual feel.

The Human Paradigm: Comfortable,Visual,Multi-Contextual

So, we’ve covered the basic paradigm of Excel, passed over the hurdles of the assessment sheets and the functional requirements – what else then do we need from a PM tool? We need it to be human-friendly.

A human-friendly data/information capture and delivery by a PM tool means two things: it’s visual, and it’s multi-contextual. I can’t think of anything that goes beyond this final layer.  A parallel layer would be  learning curve vs. ease-of-use, regardless of user background. That would complete our paradigm: a sophisticated PM tool needs to be pleasant to work with and simple enough so people can learn how to use it just by themselves, with no outside help.

There’s more about comfort and ease-of-use than we’d normally think.  Positive emotions facilitate cognition and reduce cognitive burden. When people  spend their time working with the PM tool that hinders their flow in one way or another, they get tired faster, and their higher cognitive powers “expire” faster. It’s not just a matter of pure design aesthetics or pleasant emotions. It’s about conditioning people to work more comfortably and successfully with software tools. We like nice architecture and pleasant interiors, so why should it be any different in the project workspace? The visual and omni-functional PM tool brings in a totally different quality of work for everyone involved, and I wonder why this human aspect tends to be overlooked by many. I’ve written more on the impact that software has on the human emotions (read, well-being and productivity) in the article Do You Speak Human, Software? 

Disclaimer: I didn’t mean to pitch any specific tools, or provide  reviews and recommendations, although it’s kind of more than obvious which agile PM tool is my favourite :)  My goal was to outline the paradigm to be used in the assessment of PM tools, and challenge some established patterns of thinking. When going off the beaten track, chances are high you’ll hit the bullseye of  your target board.. or process (couldn’t resist the pun :)

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. Perhaps an example would help explain this:

As a couple traveling with our family,
We want romantic activities to do together,
so that we can rekindle our love connection.

In this story, the word “activities” is pretty generic. We can replace “activities” with more specific words such as: couple’s massage, romantic dinner for two, and sunset couple’s cruise. We will get these stories.

As a couple,
we want to get a couple’s massage,
so that we can relax together and reconnect.

and

As a couple,
we want a romantic dinner for two,
so that we can have a date even more romantic than our first date

and

As a couple,
we want to go on a couples-only cruise at sunset,
so that we can enjoy romantic moments with no children around

With this technique you go from one general scenario to several more specific scenarios, each of which can be implemented separately. You will probably need some practice with this technique to get really good with it, so spend some time this week practicing! Come back in a week to learn the third technique for splitting user stories.

Here are quick links to all of the user story splitting posts.

• Introduction to User Stories and Splitting Stories
• Splitting User Stories with Conjunctions and Connectors
• Splitting User Stories with Generic Words
• Splitting User Stories with Acceptance Criteria
• Splitting User Stories with Timeline Analysis

Cheers,

Chris

Chris Sims is co-author of Elements of Scrum as well as a Certified Scrum Trainer, agile coach, and recovering C++ developer who helps software development teams improve their productivity and happiness.

The post Splitting User Stories with Generic Words appeared first on Agile Learning Labs.