Tag: Planning

Data Flow Diagrams – Are They Worth It?

Written by Aditi Sharma on April 28, 2015. Posted in Articles. 1 Comment on Data Flow Diagrams – Are They Worth It?

A picture is worth a thousand words – somebody surely captured a lot in this saying. I am a Business Analyst and I write business requirements so where does this fit in? Well, it does fit in the context of all the diagrams that a BA can leverage to put forth business requirements in concise manner. In this article, let’s explore the world of data flow diagrams.

A neat and clear data flow diagram (or DFD) can depict a good amount of the system requirements graphically. Here, the system can be manual, automated, or combination of both. A DFD shows the inputs, outputs, and how the input data got converted to output data (by a process or calculation). Focus is always on the data and how it gets transformed. It can not represent timing of a data flow i.e. whether it constantly occurs in real time, once per week or once per month. There is also no indication of when a system would run.

In order to depict movement and transformation of data, DFD uses standardized notations. There are two commonly used styles of symbols, one set developed by Chris Gane and Trish Sarson and the other by Tom DeMarco and Ed Yourdon. The difference between these two styles is just on the drawing style and nothing else. Most people in western cultures read from left to right. Therefore, BAs create diagrams from left to right.

The below mentioned is the DeMarco – Yourdon set:

Circle – Process; can not create or consume data; start with verb
Arrows (Data Flow) – Data moving in or moving out
Rectangles (External Entity) – External entities to system and may or may not be part of the organization; data Source or data receiver
Parallel Lines (Data Store) – Data at rest; Form starting point of data model; data can be moved only by a process

Most business processes are complex enough to get encapsulated in a single DFD. Hence, sets of DFDs are used for this purpose. The first DFD captures the summarized process set or scope, and further DFDs decompose the processes in details. The first DFD is popularly known as “Context Diagrams”.

The context diagram defines the “context of the system” i.e. it defines how the business process or computer system interacts with its environment, primarily external entities. This diagram is best used in early stages of requirement elicitation and can aid in further probing of the requirement without losing focus. It can also be referred to at the time of system integration testing to verify and validate.

Since detailing is mentioned in further levels of the DFD, one can often wonder how much is enough? It is recommended to limit further detailing of a context diagram to three levels only. Hence, Context Diagram > Level 0 DFD > Level 1 DFD > Level 2 DFD and then stop. If you feel that the entire system is not getting captured in three levels, then go back to context diagram and check if it should be more summarized than it currently is.

One more concept to keep in mind while decomposing a context diagram is the conservation principle or balancing. This principle states that the input, outputs, and data flows of a higher-level DFD are to be conserved or balanced in the detailed DFD. For example, if a certain context diagram has input A and output B, then level 0 DFD will also have to have the same input A and same output B. This principle would ensure that faulty diagrams are not getting created as more process detailing is being achieved in further levels of DFD.

Also, keep in mind that as the requirement elicitation stage progresses, refinements to the DFD will occur. You can not create the perfect DFD in one go. Refinements happen in an iterative fashion as requirement understanding builds further.

There are many CASE tools available in the market that help you create readable, clutter free diagrams. Tools can help align notations, use straight lines and 90-degree lines, connect various data flows, balance or process naming convention and so on. All this enhances the visual appeal of the data flow diagram and makes it easy to browse. One more important concept is grouping related items together – the way swim lanes do in flow charts. Swim lanes partition the diagram into horizontal or vertical lanes that usually represent the entity that does the work of a process. These lanes help depict the related processes in an organized and clear manner. For example, lanes can depict how interactions happen between different department units participating in a DFD.

For some readers of this article, the notes mentioned could be a recap of what they already know. But the point is, how many of us still believe in using this simple tool in our requirement gathering activity? Most of the business analysts take data flow diagrams for granted and think that it is best left in university education, but that is definitely not the case. If you probe appropriately, you will realize that this structured analysis tool is used by the project team to draw their inference of the user cases. It can be used to check for completeness and, therefore, find missing requirements. They are also great in business process re-engineering projects since they provide a sneak peek of the processes in a simplified manner. Unfortunately, it is often the under utilized tool in the Business Analyst Toolkit.

The most remarkable feature of the wonderful data flow diagram is that they are simple, effective and easily understood, including by people from non-technical backgrounds who may not like overwhelming process depictions. Do use data flow diagrams liberally whenever you can on your next project or assignment!

Don’t forget to leave your comments below.

Capacity Planning for a Balanced Backlog

Written by Robert Galen on February 9, 2015. Posted in Articles.

Todd Olson was the VP of Products at Rally Software for a few years. I met Todd when he was the co-founder of 6th Sense Analytics here in the Raleigh-Durham area. Todd’s background is mostly as a software engineer, but after Rally acquired 6th Sense, he developed a wonderful sense for product evolution and management as well.

Not that long ago, Todd made a presentation at our local Agile Leadership Network group. It was entitled: Curing Feature-itis and it focused on the balancing act associated with planning a balanced agile portfolio.

In this article, I want to bring that discussion down to the Product Backlog level and discuss some of the aspects and techniques associated with keeping your backlogs healthily balanced.

Feature-Feature-Feature (Feature3) Syndrome

When I saw the topic of Todd’s talk, it immediately resonated with my own experience. I’ve often used a term to describe a common anti-pattern that I frequently see in many Product Backlogs. I call it—Feature-feature-feature Syndrome. It implies that all of the stories (or items) in the backlog are customer-facing features—100% of them. It also implies that the backlog is incredibly imbalanced.

What’s the cause?

Well, I’m glad you asked.

One cause is the consistent business pressure that every Product Owner is under, or at least every PO that I’ve ever met. One consistency in today’s software organizations seems to be that there is always more work than there is staff (capacity) to deliver it. And this pressure lands squarely on the lap of the Product Organization and the individual Product Owners.

I’m not saying this is good or bad—it simply is.

In the Scrum model, it falls to the Product Owner to “manage” the Product Backlog. Inherently they are empowered to and responsible for what goes onto it. But when the feature pressure is on, many succumb to it and only put stakeholder or customer facing features on the backlog.

Which isn’t necessarily bad for short-term bursts of activity, but for longer-term product viability, it can be an incredibly short-sited strategy.

So what is a “balanced” backlog?

Again, good question. And the consultant in me wants to answer with – “it depends”.

Seriously though, I think the answer can be somewhat clearer. A product backlog needs to contain all of the work required to create a product or project for a client. It certainly must contain software features or functional user stories – ones that are demonstrable, otherwise, what would be the point?

But there are things in products beyond the features themselves, for example, infrastructure development, architectural work, and testing activity supporting regulatory concerns. Here’s a more complete list of some of the components of a more balanced backlog:

Development Infrastructure
Testing Infrastructure
Test Automation
Testing Environments & Data support
User Story – Research Spikes
Architectural Look-ahead or Runway activity
Design activity
Bug fixes (from longer term defect backlogs)
UX Design
Time for Testing Traceability
UAT at a system or product level

All things that I might want to capture on, and prioritize against features in a backlog. By reserving stories on your backlog, you reserve time for this important supporting work and make it transparent.

And these items, instead of coming from the stakeholders or customers, typically come from the team. In this view, the Product Owner is taking in feedback from all constituents and trying to do their best job of listening and ordering the backlog.

Who’s the boss?

Another thing to consider in your balancing act is that the customer isn’t always the boss of you. Yes in agile teams you need to drive towards delivery of value, but you also need to consider the needs of the team. Those needs often represent themselves in areas like: infrastructural, architectural, and refactoring investments; as well as in tooling for automation, testing, and code maintenance.

It’s these investments that often drive speed to market and quality improvement results. But they also reap good will and morale on the part of the team, as they feel you’re investing in their “health” as well as the product and that you’re listening to them.

A Story

In many of my Product Ownership classes I offer a dilemma to inspire thinking around balanced backlogs. I mention a hypothetical team that has a small group of database engineers on it—one is the lead and two are interns. The lead is about to go off on maternity leave for 2 months and she typically took on all of the complex back-end work for the team. While the interns have some knowledge and skill, consider what was a 2.5x productivity proposition across the three of them to be a .5 proposition with her on leave. So in essence a very significant drop in overall backend capacity.

As the Product Owner, would you alter the flow of work based on the capacity and skill-set change? Even if the business (customer, your boss, Senior Leadership) was pushing you for more functionality with significant backend implications?

Or, would you drive the work through the team independent of their capabilities simply because that was the right priority flow?

Personally, I would change the flow—balancing it towards the new capability of the team and wait for the lead engineer to return. Yes, I would make this transparent across the organization. And certainly I would also welcome some more experienced replacements, if we had them.

But I would focus on balance in the backlog even in the face of mounting “value pressure”. I think an important part of the job is maintaining your balance under pressure and adversity.

What’s the Mix?

There are essentially two ways to handle the capacity allocation mix in Product Backlogs. Either your leave it to the discretion of each Product Owner to “load” their backlogs appropriately or you define a specific target mix.

I always prefer the former approach IF the Product Owners feel empowered to own their backlogs and invest in the future of their products. But in nearly all of my experience, that isn’t the case, with the vast majority succumbing to the business pressure and creating Feature3 backlogs.

In order to combat this lack of empowered balance, many organizations negotiate a fixed ratio for their backlogs. A common one I see is 80:20; that is 80 percent features and 20 percent investment in other areas—sometimes including bug fixes. In several companies where I was the VP of Development and their internal Agile Coach, we leveraged this mix for our all of our backlogs.

What was interesting is that sometimes, we struggled to fill in the 20%, which always boggled my mind. It seemed that the teams were reluctant to write the stories to describe the 20% work, even though they continuously complained about the business’ background investments in our products.

Salesforce.com

Salesforce has an interesting twist or at least had it in the 2009-2011 timeframe*. In their case, they established a 20% “penalty” for products that didn’t minimally have 70% automation coverage, which often occurred with new product acquisitions.

What did that imply?

That they would invest in a normal mix for their products, let’s say 80:20. But if a product lacked sufficient automation coverage, they would invest an additional 20% of the backlog to bring the automation up to speed with their norms. And what’s even more interesting is that this was driven top down by management and not by the teams.

I particularly like this story because it amplifies the agile maturity of the Salesforce leadership team. They clearly understood that an investment in automation infrastructure was a longer-term investment in their products.

SAFe Recommendations

Moving on to another example. The Scaled Agile Framework (SAFe) strongly recommends a balanced approach in handling team capacity as well. But unfortunately SAFe doesn’t make any strong recommendations as to effective ratio’s or balance propositions. They simply leave it up to the organization to make that decision on a PSI by PSI basis.

While I understand that position, there are other areas within SAFe where they are quite prescriptive. I wish this were one of them. Here’s the reference for capacity allocation in SAFe.

Wrapping Up

I hope this article has at least influenced your thinking around capacity management and balance within your Product Backlogs. If you’re a Product Owner reading it, then I want you to walk away knowing that this is a significant part of your job—a job that your teams are depending on you to do well.

My main point is that you avoid Feature3 Syndrome. The other point is that it will take dogged determination, a longer-term view, and courage for you to maintain a healthy balance—particularly under pressure. While that may be a great challenge, your team will respect you for it and your products will be more successful if you achieve that balance.

In the end, it’s your choice.

Stay agile my friends,
Bob.

Don’t forget to leave your comments below.

*Salesforce mentioned this at several conference presentations in that timeframe. One noteworthy example was at the Agile 2010 conference. I believe Steve Greene was the co-presenter.

Don’t Be a Victim, Break the Rules

Written by Charles Gallagher on December 22, 2014. Posted in Articles. 1 Comment on Don’t Be a Victim, Break the Rules

“You are remembered for the rules you break.”
Douglas MacArthur

Anyone who has studied the history of medicine will notice that some of our biggest breakthroughs have been the result of a single scientist breaking the rules. History tells us these are the same people who have also effectively changed a conventional paradigm. For example, the world is flat, wash your hands, earth revolves around the sun. Often times, the rule-breaking scientist pays a considerable price for being a change agent. The pain of change forces an outlandish idea to become a piece of conventional wisdom.

Even in the social sciences, we often see rule breaking as a means to progress and enlightenment. Just look at Rosa Parks and others like her during the Civil Rights Movement. Nelson Mandela in the face of Apartheid. Ronald Reagan challenge to Gorbachev to tear the wall down.

We face outlandish ideas (rules) in the work place all the time. One popular one is “this is the way we have always done it.” How many times have we heard that? Breaking this single rule can often yield great rewards in professional wisdom and in productivity. In our often over-stimulated, over-technical workplace environment, we often find ourselves powerless in the face of bureaucratic electronic fences and complexity. It is easy to get overwhelmed, easy to submit to the way we have always done things. I have found in my career that people often follow rules simply because of inertia or because no one is measuring outcomes in a meaningful way.

When we measure our outcomes and keep score during our work it becomes increasingly more difficult to utilize flawed logic or to cling to the way we have always done it. It forces us to break the rules. It forces us to stop being victims to the mindless way in which we often work.

Often when we are executing projects the biggest operating constraints are the rules established by the firm. Many times these rules are really just old habits and typically they have no logical, timely or relevant basis other than “this how we have always done it.” Many firms cannot let go of their stodgy industrial mindsets and cultures (even though most of them have been hard at work in a knowledge economy for quite a long time now). The firms brave enough to break the rules are truly emerging and re-emerging, boosting productivity, increasing effectiveness and accelerating execution speed.

This week examine your daily routine and ask yourself what rules could I break? When running a project, challenge yourself to play the curious anthropologist— ask why you do what you do. The movie Office Space was infamous for outlining the ludicrousness of the TPS reports. My guess is that you have your own TPS reports in your organization. The bottom line is simple: If the rule is not adding value or making life better for someone it probably should be broken.

Don’t forget to leave your comments below.

Grooming, Maintaining, or Refining your Backlogs – Practices for Success, part-1

Written by Robert Galen on December 15, 2014. Posted in Articles.

In 2009 I wrote the first edition of Scrum Product Ownership as a way of helping Product Owners understand their roles and responsibilities better. Before that, it was mostly an exercise in guessing and survival. In 2013, I updated the book in a second edition . In both books I took on the topic of Backlog Grooming.

As it turns out the term “grooming” is losing its luster in the community and terms like maintenance and refinement are replacing it. I believe the latest copy of the Scrum Guide uses the term refinement. So I will try to start using Backlog

Refinement consistently throughout this article. That being said, I really, really like the implications of the term grooming.

Backlogs & Refinement

Why don’t we first start with a definition of Product Backlog. From the July 2013 Scrum Guide, I’ve captured the following:

The Product Backlog is an ordered list of everything that might be needed in the product and is the single source of requirements for any changes to be made to the product. The Product Owner is responsible for the Product Backlog, including its content, availability, and ordering.  

A Product Backlog is never complete. The earliest development of it only lays out the initially known and best-understood requirements. The Product Backlog evolves as the product and the environment in which it will be used evolves. The Product Backlog is dynamic; it constantly changes to identify what the product needs to be appropriate, competitive, and useful. As long as a product exists, its Product Backlog also exists.  

The Product Backlog lists all features, functions, requirements, enhancements, and fixes that constitute the changes to be made to the product in future releases. Product Backlog items have the attributes of a description, order, estimate and value.

And because this article is about Backlog Refinement, let’s see what the Scrum Guide has to say about it as well:

Product Backlog refinement is the act of adding detail, estimates, and order to items in the Product Backlog. This is an ongoing process in which the Product Owner and the Development Team collaborate on the details of Product Backlog items. During Product Backlog refinement, items are reviewed and revised. The Scrum Team decides how and when refinement is done. Refinement usually consumes no more than 10% of the capacity of the Development Team. However, Product Backlog items can be updated at any time by the Product Owner or at the Product Owner’s discretion.

Higher ordered Product Backlog items are usually clearer and more detailed than lower ordered ones. More precise estimates are made based on the greater clarity and increased detail; the lower the order, the less detail. Product Backlog items that will occupy the Development Team for the upcoming Sprint are refined so that any one item can reasonably be “Done” within the Sprint time-box. Product Backlog items that can be “Done” by the Development Team within one Sprint are deemed “Ready” for selection in a Sprint Planning. Product Backlog items usually acquire this degree of transparency through the above described refining activities.

Now that we’ve explored what a Product Backlog and Refinement is, by process definition, let me share some of my experiences around effective refinement.

12 Tips for Effective Backlog Refinement

Regularly Scheduled Refinement Meetings – I’m a big fan of creating a tempo of regularly scheduled Backlog Refinement meetings within your teams. I usually schedule 1-2 of them a week for an hour each. The entire team is invited and expected to attend. I want everyone to come to the meeting “backlog aware”, that is, they’ve looked at likely refinement candidates before the meeting AND they have thoughts surrounding (size, ordering, design, dependencies, strategy, quality, risks, and optimal flow).
I also recommend that a team member take detailed notes that capture the valuable discussions and next-step decisions that are made. This is invaluable information and you don’t want to lose it. I normally ask members to round-robin note keeping, which helps to keep everyone engaged in the meeting, and in the backlog.
Rigorous Prioritization – You must truly reinforce the notion of order or priority in your backlogs. I think of the Highlander movies and the phrase – “There can be only One” in this regard, so please don’t overload priorities
From my perspective there are a variety of factors that should influence priority:
- Customer value (right problem solved)
- Business value (revenue generated)
- Technical value (fosters learning, reduces risk, solid solutions, intelligent workflow)
- Quality value (mitigated risk or improves quality)

And I look for the team to consider and balance against all of these variables when setting priority. For example, it should never be the case that customer value always drives prioritization without consideration of technically sound solutions.

Examine Your Stories Frequently – I often encounter teams who only refine their stories once. In that context they write them, refine the wording, write acceptance tests, estimate them, and order them – all at the same time. I could see doing that for trivial or straightforward stories, but never for complex ones.
I much prefer an approach where the team “samples” the stories over several refinement meetings. Taking the story from concept or idea (Epic) and methodically breaking it down into refined and executable stories. I sometimes recommend to teams that—a “good story” should be refined a minimum of 3-4 times during its evolutionary lifetime. And this includes sufficient space in between refinement discussions so that the team has time to think about the story in relation to all of their other work and the project and product goals.
Egg Timer – I usually recommend that teams stay aware of their story refinement velocity, that is, how many stories do they discuss in a 1-hour meeting. I often see velocities of 1-2-3 stories, which to me implies over –discussion. I prefer the team have a goal of “advancing” stories in their refinement meetings and not necessarily complete them in one sitting.
The real point of a backlog refinement meeting is not to complete stories as quickly as possible, but to advance the understanding and clarity around the stories. As long as the team makes progress, and keeps chipping away at the stories, I’m happy with their progress. You might ask, what is a fair or rough velocity goal? I’m not sure there’s a magic number, but refining a story every 5-6 minutes might be a reasonable goal—so perhaps 10-12 per 1-hour meeting.
The Estimates are NOT the most important thing – We’re in the middle of a refinement meeting and leveraging Planning Poker as a means of collaborative estimation. In one case, 2 developers have been debating whether the story is 5 or 8 points in size for the last 30 minutes. Eventually, the Scrum Master has to move on and the team still hasn’t agreed on the estimate. In another case, the testers on the team think a story is 13 points, but the developers strongly disagree. And the story ends up being estimated at 3 points. After this happens a few times, the testers disengage in the estimation and simply acquiesce to the developers on all estimates.
In both cases, the estimates (numbers) have been the focus point of the team. I strongly would argue that the estimates are much less valuable than the DISCUSSION that the process of Planning Poker estimate enables.

Who cares if it’s a 5 vs. an 8? At the end of the day, pick a reasonable, relative value and move on. BUT, have rich, deep, collaborative discussions across the team about the story. Hear everyone’s experience. Hear their concerns. Listen to what’s said and unsaid. And as a team, come to a fair and balanced relative estimate for “all the work” to move the story to meet your Definition of Done. That’s the value that the estimates drive.

Wrapping Up

I hope I’ve established some baseline thinking on your part regarding the practice of Backlog Refinement. From my perspective, it’s much more than simply developing agile requirement lists. It’s also the planning and strategy part of agile execution and it makes all the difference in how well your sprints are delivered.

In the next post, I’ll finish delivering tips 6-12 and wrap-up this topic. I hope you “tune in” for the remaining tips, until then…

Stay agile my friends,
Bob.

Don’t forget to leave your comments below.

Effective Brainstorming Practices

Written by Dr. Surya M. Ganduri on November 3, 2014. Posted in Articles. 2 Comments on Effective Brainstorming Practices

Have you been getting frustrated with brainstorms and have stopped using them? Rest assured, you are not alone.

Brainstorming practice, once used to be the most popular group creativity exercise in business, has become old-fashioned and no longer considered effective in many organizations. But the real reason for their frustration is typically that the brainstorming meetings are not facilitated properly.

A well-run brainstorming meeting is fun and energetic. It is quick, easy and it works. It will generate plenty of good ideas. But a poor session can be frustrating and demotivating. Let’s look at some simple ways to ruin your next brainstorm meeting – so you understand what practices you should avoid.

1. Have an Independent Facilitator

Beware of having an autocratic boss with his or her team. Don’t let your boss be the moderator. He or she can inhibit or shape the discussion in undesirable ways, and can often inhibit the group’s creativity. If the boss is present then it is better to have a good independent facilitator – someone who can encourage input from everyone and stop one person from dominating. The worst formula for a brainstorming session is generally the department manager leading the team and acting as scribe and censor at the same time.

Most brainstorming sessions follow a power curve. They start out slowly, build to a crescendo, and then start to plateau. The best facilitators nurture the conversation in its early stages, step out of the way as the ideas start to flow, and then jump in again when energy starts to peter out.

2. Have Clear Objectives

A brainstorming session with a vague or unclear purpose will wander and lose its way. So be sure to set a clear objective for your meeting. The purpose of the brainstorming session is to generate many creative ideas to answer a specific goal. It is best to express the goal as a question. A general objective is not helpful. For example, “How can we do better?” is not as good as “How can we double sales in the next 12 months?” However, the question should not be too detailed, or it may close out lateral possibilities. To follow our previous example, “How can we double sales, through existing channels and with the current product set?” is probably too constrained. Once the question has been agreed it is written up clearly for all to see.

Caveat: If your goal is to just “collect the creative ideas that are out there,” group brainstorms are a waste of time. A Web-based system for collecting ideas or an old-fashioned employee suggestion box is good enough.

3. Set a Time Limit

It is worth setting objectives for the number of ideas to be generated and the time to be spent. “We are looking to generate 60 ideas in the next 20 minutes. Then we will whittle them down to 4 or 5 really good ones.” For best results, your brainstorming session should not be too long – around 30 (+/- 5) minutes is generally best.

4. Diversity of Group Members

Figure: Group Think

If everyone is from the same department, then creativity can be inhibited and you may get “group think.” Choose the members of your group carefully; the best size is somewhere between six and twelve people. Too few people and there are not enough diverse inputs. Too many people and it is hard to control and retain everyone’s commitment. Sprinkle the group with a few outsiders from other areas or even from outside the business – people who can bring some different perspectives and wacky ideas. A good mix of people – varied ages, men and women, works best.

5. No Criticism

The most important rule of brainstorming is to suspend judgment. In order to encourage a wealth of wacky ideas, it is essential that no one is critical, negative or judgmental about an idea. Any idea that is uttered – no matter how stupid – must be written down. The rule about suspending judgment during the idea generation phase is so important that it is worth enforcing rigorously. A good technique is to issue water pistols; anyone who is critical gets squirted.

6. Settling for a Lots of Ideas

Don’t get a handful of ideas and then start analyzing. Quantity is great. The more ideas the better. Brainstorming is one the few activities in life where quantity improves quality. Think of it as a Darwinian process. The more separate ideas that are generated the greater the chance that some will be fit enough to survive. You need stacks of energy and buzz driving lots of wacky ideas. Crazy thoughts that are completely unworkable are often the springboards for other ideas that can be adapted into great new solutions. So keep the crazy ideas coming – you have to kiss a lot of frogs to find one prince!

7. Follow Through

Don’t stop the meeting after generating lots of ideas with a vague promise to follow up. If people see no real outcomes they will become frustrated with the process and lose faith. You should quickly analyze the ideas at the meeting. One of the best ways is to divide the proposals into three categories – promising, interesting, or reject. If any of the promising ideas are real no-brainers – so good that they should be implemented immediately – give them to someone as an action item immediately.

Caveat: Don’t Reward. The worst thing you can do is set up the session as an “I win, you lose” game, in which ideas are explicitly rated, ranked, and rewarded. If you reward giving bonuses (or gifts) to people who generate “the best” ideas in brainstorms, the resulting fear and dysfunctional competition will drastically reduce the number of ideas generated by what can be a creative and cooperative group process.

You should categorize and collect the ideas. On a separate flipchart, write all the promising and interesting ideas which are marketing ideas, on another chart all the sales ideas, etc. This process of rearranging the ideas can help you see new combinations and possibilities. Some people use Post-It notes at this stage so that they can easily move ideas around.

If you are pressed for time, then an alternative method of selecting the best ideas is to give everyone five points. They can allocate points to their favorite ideas in any way that they want. They can give one point to five separate ideas or all five to one idea. After everyone has voted, total the points and select the best for further action.

Close the meeting by thanking everyone for their input. Mention again one of two of the best, most inventive or funniest ideas. Then see which ideas you can implement – even if they are small things.
People enjoy short, high-energy brainstorms that lead to actions. These meetings can motivate people, improve efficiency and drive innovation.

Don’t forget to leave your comments below.