Search This Blog

If a comment gets added to a Team, but no one hears it...

Does it still make a sound?  Maybe, but we have a few different places to make our comments heard within a Microsoft Team.  Which choice is best?  The consultant says "it depends."

First, our options...

Each time you create a new Team, you automatically get three places to record your thoughts, pearls of wisdom, snappy comebacks, notes of encouragement or pithy remarks.

  1. Channel Conversation (chat with your team)
  2. OneNote (record notes with your team)
  3. A wiki (similar to OneNote but web pages)


Conversations are basically just chat messages that are shared among the members of the team and persisted over time.  You get one conversation per channel.  A simple explanation, however, does not mean this isn't a very powerful way to share comments within the Team.  

If those comments are directed toward someone, using the @ and their name will notify them.  When you add a document, you can also post a message to the conversation announcing its arrival.  Uploading a file directly to the chat also adds it to the files tab (and the SP library behind the scenes).

Connectors may be used to allow external data to flow into the conversation as it is added at the source.  For example, you can connect a Yammer group to a channel conversation and have the messages automatically display in Teams.

Perhaps most importantly, you can add emojis, animated gifs, stickers, and memes (start with an image and add your own text) to chat messages.  Angry cat would never show his face on the wiki but you can add him all over the place in a conversation.  Just saying...


When a Team is created, a modern SharePoint team site is created behind the scenes.  A OneNote notebook is provisioned with that site.  By default, there is no link to the OneNote from Teams itself.
That can easily be remedied by clicking the "+" and adding a tab.  When you select OneNote, it automatically links to the notebook living in the SharePoint site and creates a new section.  The name you provide is for the tab and the section.

OneNote Online opens in Teams when you click the tab, so you can stay put and edit your OneNote pages with the same ribbon UI.  The option exists, of course, to open in OneNote  directly or OneNote Online in its own browser window. The advantage of this tool is that you can leverage your knowledge of OneNote even while using Teams. The consistency of the experience (across OneNote apps on all your devices and desktop) makes this a far better alternative than the wiki in my opinion, and essentially accomplishes the same goal.

You can also add more OneNote notebooks into the Documents library directly.  We can do this in SharePoint by going to the library, clicking "New" and adding a OneNote notebook.  To see the file in your channel, make sure to add it to the correct folder. Unfortunately, clicking new on the Files tab in Teams doesn't show you OneNote as a document type.  You could also do this from OneNote if you prefer (Share a Notebook on a SharePoint site).

You'll have to open these notebooks by clicking on the file in the Files tab.  I've not seen a way to add a dedicated Teams tab to navigate into these additional notebooks.


The link to the wiki is always there waiting for you in a new channel.  It would almost seem that makes it the preferred way to put together shared notes, but OneNote is far more flexible.  The formatting on the wiki is more limited as well, with a more simplified ribbon.  

Behind the scenes, the wiki is stored in the "Teams Wiki Data" document library in SharePoint as a series of .mht files, one per channel.  It's up to your browser to handle that extension.  In Firefox, I'm prompted to download the file.  So, if you want to see and interact with it, going back to the Teams channel may be the best bet.  

I have some customers who are still avid users of SharePoint wikis, so if this is your "easy chair of collaboration," go for it.  Just remember, in wikis, it is pages 1st and sections 2nd.

Still Conversing

These, of course, are not mutually exclusive options.  You can use all three, all the time, if you choose.  Conversations, however, seem to be the real key to collaboration in Teams.  Just like the Dude's rug, they really tie the room together.  

You can click the speech bubble to the right of a section in your wiki to add a conversation about it that is recorded in your channel.  That same speech bubble is in the upper right when you click on a OneNote tab.  So you can make notes about your notes.  The speech bubble even shows up when viewing a file in Teams so you can keep a running commentary about your document.  These messages are all part of the running, persistent, searchable thread of messages kept in each channel.

Shepherding User Requirements

Business requirements are like sheep. I bet they are roaming free inside your organization right now. To have successful IT projects that truly address the needs of the business, the requirements (like sheep) need to be gathered using the right tools and guided to safety.
They must be gathered.
Sheep may travel together or wander off on their own, but eventually they need to all be pointed in the same direction, walking toward the same goal. When it comes to making a project successful, all user requirements have to be accounted for.   Those requirements express the must haves, needs, wants and wishes for your project.
They may already be documented, but a great many may reside in the minds of your stakeholders. Maybe the requirements are for a new process that does not currently exist. In the end, the only way a project can be proven successful is if the end results fulfill the business requirements.  They must first be gathered – pulled from the bushes, called from afar and assembled.  A thorough BRD (business requirements document) may be the perfect pen in which to keep all those sheep, uh . . .  requirements.
They benefit from the right tools.
Just like the shepherd’s crook, the right tool can make the work of gathering easier. Your requirements must be documented and agreed upon. Using tools like Excel or Team Foundation Server to create groups of functionality, or features that group user stories together can be very effective. Each requirement or story gathered from a user can be corralled into separate features to better organize them for later.
These user stories provide the backlog of work to be done and can be paired with acceptance criteria to ensure success. The backlog can be used to generate and prioritize project tasks and help to drive the effort toward a well-defined end. The business requirements should drive the work, and the right tools make sure that our well documented requirements are being fully addressed.
They must be guided.
So it’s not enough to gather all the sheep and point them in the right direction. They have to be guided and cared for – fed, watered, groomed and nurtured. Creating a backlog of user stories is a great first step, but those stories must be guided throughout the life cycle of the project. The term “grooming of the backlog” fits our sheep metaphor pretty well.
Requirements will change over the life of the project. They may grow and mature or even become obsolete. Maybe you pick up some new sheep as you go. Maybe some try to wander off when you’re not paying attention to them. Depending on your project methodology, you may gather as many requirements as possible up front or choose to gather them as you go. Either way, you must be prepared to deal with changes in scope, definition and order.
They must be protected.
The keen eye of a good shepherd is always on the lookout for potential threats. The wolves are watching and waiting for their opportunity to pounce. The primary threat to requirements, like sheep, is losing them along the way. Good requirements shepherding demands that requirements are seen all the way through the project life cycle, from eliciting to documenting to prioritizing to developing to testing and on to user acceptance. The business analyst is the shepherd to own the sheep and own their well-being.
Making sure your requirements are gathered well, watched closely and carried all the way through your project is a key to success.  Fully understood and vetted requirements will lead to a concise scope, happy stakeholders, higher user adoption of your software and increased ROI.   I’ll be talking more about how to use TFS as our tool of choice for shepherding requirements, so pick up your shepherd’s crook and come along.